When you startup a standard trace the first settings you see will be the current database connections.
In my case there is about 10 entries, all of whome are the same username, however some are dateformat dmy and some are mdy. The asp website seems to pick a connection from the pool and uses it, it appears to pick one of 3 and all are set to dmy however every connection should be mdy. Since they are all the same username and that user is set to us_english where else might the connection be getting the dateformat entry?
Thanks
Some ideas:
The application is issuing SET DATEFORMAT
The app is using a DSN with/without translation
By default, the connection default is defined by SQL Server default settings.
Related
I am working on a migration project where we are migrating one application from Weblogic to Websphere 8.5 server.
In Weblogic server, we can specify default schema while creating datasource but I don't see same option in WebSpehere 8.5 server.
Is there any custom property through which we can set it , I tried currentSchema=MySchema but it did not work.
This answer requires significantly more work, but I'm including it because it's the designed solution to customize pretty much anything about a connection, including the schema. WebSphere Application Sever allows you to provide/extend a DataStoreHelper.
Knowledge Center document on providing a custom DataStoreHelper
In this case, you can extend com.ibm.websphere.rsadapter.Oracle11gDataStoreHelper.
JavaDoc for Oracle11gDataStoreHelper
The following methods will be of interest:
doConnectionSetup, which performs one-time initialization on a connection when it is first created
doConnectionCleanup, which resets connection state before returning it to the connection pool.
When you override doConnectionSetup, you are supplied with the newly created connection, upon which you can do,
super.doConnectionSetup(connection);
Statement stmt = connection.createStatement();
try {
stmt.execute(sqlToUpdateSchema);
} finally {
stmt.close();
}
doConnectionCleanup lets you account for the possibility that application code that is using the connection might switch the schema to something else. doConnectionCleanup gives you the opportunity to reset it. Again, you are supplied with a connection, upon which you can do,
super.doConnectionCleanup(connection);
Statement stmt = connection.createStatement();
try {
stmt.execute(sqlToUpdateSchema);
} finally {
stmt.close();
}
Note that in both cases, invoking the corresponding super class method is important to ensure you don't wipe out the database-specific initialization/cleanup code that WebSphere Application Server has built in based on the database.
As far as I know Weblogic only allows setting a default schema by setting the 'Init SQLto a SQL string which sets the current schema in the database, such asSQL ALTER SESSION SET CURRENT_SCHEMA=MySchema`. So, this answer is assuming the only way to set the current schema of a data source is via SQL.
In WebSphere, the closest thing to WebLogic's Init SQL is the preTestSQLString property on WebSphere.
The idea of the preTestSQLString property is that WebSphere will execute a very simple SQL statement to verify that you can connect to your database properly when the server is starting. Typically values for this property are really basic things like select 1 from dual', but since you can put in whatever SQL you want, you could setpreTestSQLStringtoSQL ALTER SESSION SET CURRENT_SCHEMA=MySchema`.
Steps from the WebSphere documentation (link):
In the administrative console, click Resources > JDBC providers.
Select a provider and click Data Sources under Additional properties.
Select a data source and click WebSphere Application Server data source properties under Additional properties.
Select the PreTest Connections check box.
Type a value for the PreTest Connection Retry Interval, which is measured in seconds. This property determines the frequency with which a new connection request is made after a pretest operation fails.
Type a valid SQL statement for the PreTest SQL String. Use a reliable SQL command, with minimal performance impact; this statement is processed each time a connection is obtained from the free pool.
For example, "select 1 from dual" in oracle or "SQL select 1" in SQL Server.
Universal Connection Pool (UCP) is a Java connection pool and the whitepaper "UCP with Webshere" shows how to set up UCP as a datasource.
for JDBC datasource, the steps are similar but, you can choose the default JDBC driver option.
Check out the paper for reference.
In my ASP.NET application, I am getting the following error:
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
But I can successfully connect to the database server using 'SQL Server Mangement Studio' and I can also correctly PING the host where SQL Server is hosted.
What can be wrong here.
Check your connection string in web.config. The connection string you are using via SQL Management Studio is different to the one in the web.config.
You can increase timeout in web.config too which is better or say best approach.
Also whenever you get this type of error and everything is good in confirable, then first debug the code,
if the issue code side, then you manage simply by changing logic.
If it is sqlserver side, then get the parameter value and sp or query. Run in to SSMS which gives you better idea.
Increasing Command timeout to 120 fixed my problem for me.
adapter.SelectCommandCommandTimeout=120;
I am new to ASP. I have two databases production and developer databases.
I need to check developer site is going to developer database or not. Both databases have same data and same table names.
But i must work on developer database only how can I?
Generally you'd have an environment configuration file. If you're talking about ASP.NET then it would be the Web.config file. If you're indeed talking about classic ASP then it would probably be an included script with some constants.
If the databases are structurally identical (which they should be) then all you should need to change is the connection string. For classic ASP, you'd probably just store it in a variable:
Dim connString = "This is your connection string"
On the production server, the connection string would be set to your production database. On development machines, it would be set to a development database. (And so on for a test environment, etc.) All of the data access code would just use this connection string variable.
Even more to the point, this should not be the only thing that prevents a developer from using the production database. The DBA should set the permissions such that only the production application has only the access it needs to that database and others do not. Developers should never be able to accidentally modify the production database. So even if you did use the production connection string from your workstation, the database should simply deny you access.
Have two connection strings. Then create a constant variable which will act as your switch and pick the correct connection string:
Dim strCon
CONST DEVELOPMENT = true
if(DEVELOPMENT = true) then
strCon = "Development connection string"
else
strCon = "Live connection string"
end if
adoCon.open strCon
Then you can simply change the switch to true/false depending on which database to pick.
When you specify the database connection you know where you are pointing, so this should be straightforward. But it might be a good idea to use separate logins on dev and production.
So the answer is that you should use the connectionstrings in the config files to get what you need: the "database =.." setting should be set correctly and your problem is aolvedsolved To get extra certainty use different logins, which is recommendable in any case.
you can also use server tracing to monitor activity, but it is not easy on a multi user database and is only a diagnostics tool, not a cure.
I have a reportviewer (Microsoft.ReportViewer.WebForms) control on my page. All my reports use one data source. I want to be able to let my reports run on a different database when started from my UAT enviroment. So the location of the reports is the same, but the data comes from a different db. I cannot seem to find how this is done, is it even possible?
EDIT: They are server reports on SQL Server . I know you can set the dataset programmaticaly but I just want the reports to point to a different db and leave the rest of the report intact.
2005
TIA,
John
Did you want to pass a full connection string to the report as a parameter? You can do it but sometimes SSRS gets funny and make sure you delete the report off the server before you deploy a new copy when doing this...
1. Make a parameter - let's call ours connectionStr. Make it not null, not blank, single select and text as the data type. Eventually, you will want to hide this parameter but for testing please leave it visible.
2. So the value you will be using as the connection string... (for testing I set this as the default for the parameter, with nothing put under the available values section) Data Source=MySQLServerName;Initial Catalog=MyDatabaseName;Persist Security Info=True;User ID=MyUserNameForTheServer;Password=MyPasswordForTheServer;MultipleActiveResultSets=True
3. You need an unattended execution account on your report server or you get this: unattended execution account is not specified. (rsInvalidDataSourceCredentialSetting). http://msdn.microsoft.com/en-us/library/ms156302.aspx I can't provide more details because my boss had to do this part for me.
4. Under your datasource properties in SSRS... check Embedded Connection, select the type (mine is just a normal MS SQL Server), for the connection string, open the expression box and put: =Parameters!connectionStr.value and then click credentials and make sure the last option for no credentials is selected.
5. Your datasets for that datasource will no longer be happy when you try to edit them in design view but you can switch the datasource connection properties back to how they were, not using the parameter based connection string, for editing them.
My reports are on different servers, with different instances of the Report Server, too. On some servers, they need to get their data from various databases depending on whatever, stuff. This way, with the connection string as a parameter, I can use the same reports everywhere and just deploy them to the different servers. If you are having to pass this connection string around your app or to a report viewer, I suggest using encryption.
Like I said... SSRS get's funny when you start doing this, though. Your reports should always work in preview mode after doing this, if they don't even when provided with the correct connection strings, then you have an issue that won't be solved by just deploying to the server. Trouble shooting problems with this once they are on the server but not working include checking permissions, making sure the report receives the correct connection string and making all your stored procedures and functions within the SQL database are all the same.
If you want to just pass the database name and everything else is the same (server name, username, password) then just set the connection string parameter equal to your database name and for the datasource expression value use
="Data Source=MySQLServerName;Initial Catalog=" + Parameters!connectionString.value + ";Persist Security Info=True;User ID=MyUserNameForTheServer;Password=MyPasswordForTheServer;MultipleActiveResultSets=True"
I needed to pass the whole thing in, and you can play around with the credential settings - you might be able to save the server username/password info in there for each report so that the unattended execution account is not needed.
We recently launched a new web site... there are roughly ~150 users active during peak hours. During peak hours, we are experiencing an issue every few minutes, the exception text is listed below.
System.Web.HttpUnhandledException:
Exception of type 'System.Web.HttpUnhandledException' was thrown.
---> System.Data.SqlClient.SqlException: The client was unable to establish a connection because of an error during connection initialization process before login.
Possible causes include the following:
the client tried to connect to an unsupported version of SQL Server;
the server was too busy to accept new connections;
or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: Named Pipes Provider, error: 0 - No process is on the other end of the pipe.)
Our data access layer calls various DataTableAdapters using the following syntax.
EDIT
Yes, da is the name assigned to the DataTableAdapter. There is no connection.Open() because the DataTableAdapter takes care of all that, right?
using(TheDataLayer.some.strongly.typedNameTableAdapters.suchAndSuchTableAdapter da = new TheDataLayer.some.strongly.typedNameTableAdapters.suchAndSuchTableAdapter())
{
StronglyTyped.DataTable dt = new StronglyTyped.DataTable();
da.FillByVariousArguments(dt, ..., ...);
//da.Dispose();
return something;
}
The connection string looks something like:
<add name="MyConnectionString"
connectionString="Data Source=myDBServerName;Initial Catalog=MyDB;User ID=MyUserName;Password=MyPassword"
providerName="System.Data.SqlClient" />
I'm trying to rule the problem being in Code. Is there anything "simple" that can be done to minimize this issue?
Thanks.
Have you tried "Connection Pooling" directly in connection string settings?
Example:
connectionString="....;Pooling=true;Min Pool Size=1;Max Pool Size=10;..."
You can read more info here: http://msdn.microsoft.com/en-us/library/8xx3tyca%28v=vs.71%29.aspx
Without seeing the code that actually opens and uses the connection, it's hard to say where the problem is.
Please update your question with what happens when you create that DataAdapter (I'm guessing that's what da means).
Also, if you're using the using statement, you shouldn't be disposing of the thing you created the using statement for.
We had similar issue which only happenes in our production environment and it was particularly associated with load. During busy time of day we would recieve several of the above mentioned exception.
We gone through a massive investigation around why this exception occurs and did a lot of changes to fix the issue. The defacto change we did which aleviated the problem was connection pool setting by setting min pool size to 1 and max pool size to 10. (It can vary based on your situation)
This issue will be more prevalent when you have several i.e. 1000's of Customer DB and use default connection string (i.e. database=DBName;server=ServerName). We were not explicitly setting min/max pool size hence it took default settings which set Min pool size to 0 and max pool size to 100.
Again, I dont have concrete proof but the theory is that during busy time of the day based on load it made several connection to DB server and DB server was bombarded with a lot of connection request at single point to several databases. Either Application server or DB server did have bandwidth to handle that many connection in a short period of time. Also, it was happening with server with most databases. Though we did not see a lot of connection at a time but Application server was not able to make connection to databases for a short duration when it had surge of requests going in.
After we set min pool size we aliveated this problem as there is atleast one connection to each database which is available all the time and if there is blast of request which required to make connection to several databases we already had atleast one connection to the database available before we request a new one.
Maybe unrelated to the actual problem you were facing, but this error is also thrown if you are trying to connect without specifying the correct port along with the database server name.