I have some VBA that queries a SQL database using ADODB. Currently I have the CommandTimeout set to 30 seconds. If nothing is returned, that can either be because no such record exists in the SQL database, or because the timeout was reached. I would like to be able to distinguish these two cases and display a warning when the timeout is reached. Is there a way to achieve this?
Firstly read this: ADO Event Instantiation: Visual Basic
Check EventStatusEnum for adStatusOK - which should not be set in case TimeOut.
You could also catch up "InfoMessage"
InfoMessage Event to see information like in SSMS when you run query.
Has anyone ever encountered a problem where a SQL query from a classic ASP page returns partial results, but no errors?
I have a situation where a particular query on a page (one of many throughout the system) is returning a different number of rows each time it is run, and always less than the "correct" number, as determined by running the SQL against the server directly.
I think this may be related to the connection timeout (since this occurs with a long-running query and my timing shows that it is returning very close to the timeout), but I am receiving no timeout errors. Instead, as far as I can tell, it causes no errors, and returns a valid DataSet which the code then loops over to build the results table.
Since there is no indication that an error has occurred, there is no suggestion that the data is not complete which means that users can no longer trust this report. Generally with this system, where SQL timeouts do occur frequently for "large" queries, we get error messages displayed on the page.
Investigations
I've check the HTML source to make sure there are no injected error's that I'm missing and that all tags are well-formed and that expected page elements are present. This indicates it's not an error writing a particular row from the results.
** Furthermore, the number of rows returned is different each time.
I've verified that the exact same query is being run each time.
I've verified that the data in the DB is not changin underneath the report (it's historic and I've cross-checked by running the report and the query against the DB at the same time.)
I've tried to manually print any errors from the query, but get nothing.
I've tried changing the timeout (though this hasn't helped as I can only do
this on the Dev environment and there there is not sufficient data in
the DB to reach the timeout, due to this issue.).
There are only around 20 rows in total expected, so not an issue with a very large dataset.
Has anyone run into a situation where a SQL query from a classic asp page only returns partial results, and is there any way to check for or prevent this condition?
Setup:
Classic asp web application
Heavy use throughout of ADODB.Connection objects for connecting to the DB2 server backend databases.
The database is static as far as the queried data is concerned.
Shared connection initilization as follows:
connString = "Provider=MSDASQL.1;User ID=xxx;Data Source=XXX;Extended Properties=""DSN=XXX;UID=XXX;PWD=XXX;"""
Set conn = Server.CreateObject( "ADODB.Connection" )
Set cmd = Server.CreateObject("ADODB.Command")
conn.Mode = adOpenReadOnly
conn.Open connString
cmd.ActiveConnection = conn
cmd.CommandTimeout = 600
Usage as follows:
query = " SELECT blah FROM Foo WHERE ... " ' big long list of clauses defined from user selections.
cmd.CommandText = sql
Set oRs = cmd.Execute
Resposne.Write "<table>..." ' Write table headers here'
Do while (Not oRs.eof)
Response.Write "<tr>...</tr>" ' WRite details from oRs here
oRs.MoveNext
Loop
Response.Write "</table>"
Try adding an order by to the query, that way it should send all rows at once and you can rule in or out timeout issues
Using TADOConnection class to connect to SQL server 2005 db.
Having ConnectionTimeOut := 5; // seconds.
Trying to open the connection synchronously.
When the server is available and running, the connection time out works fine. If the server is not available or network connection is lost, then attempting to open a connection waits for more than 5 seconds (may be 20 secs).
Is there any property or method that needs to be set to influence this behavior?
No, it's enough to set the ConnectionTimeout property
I've had the exact problem (D2009, MSSQL2005), but TADOConnection.ConnectionTimeout works fine for me (btw. the deafult value for this property is 15 seconds). Note, that the timeout dispersion is quite wide, so once you'll be timed out after 5 seconds and later on e.g. after 10 seconds, but 20 seconds is really too much for the connection attempt.
Probably you have a problem with CommandTimeout (if you are trying to execute a query with the associated ADO data set component). You need to remember, that if you set TADOConnection.ConnectionTimeout := 5 and in your data set component e.g. TADOQuery.CommandTimeout := 15, and you're trying to execute query, then you will get timeout after 20 seconds.
If you really have a problem with query execution, not only connection attempt, this post may help you
ADO components CommandTimeout
TADOConnection.ConnectionTimeout - Timeout in milliseconds to connect to data source
TADOConnection.CommandTimeout - Timeout in milliseconds to execute command
if you getting timeout error on trying to connect, increase value of ConnectionTimeout property, else if you getting an error on executing some query, - increase value of CommandTimeout property.
We got a legacy vb.net applicaction that was working for years
But all of a sudden it stops working yesterday and gives sql server timeout
Most part of application gives time out error , one part for example is below code :
command2 = New SqlCommand("select * from Acc order by AccDate,AccNo,AccSeq", SBSConnection2)
reader2 = command2.ExecuteReader()
If reader2.HasRows() Then
While reader2.Read()
If IndiAccNo <> reader2("AccNo") Then
CAccNo = CAccNo + 1
CAccSeq = 10001
IndiAccNo = reader2("AccNo")
Else
CAccSeq = CAccSeq + 1
End If
command3 = New SqlCommand("update Acc Set AccNo=#NewAccNo,AccSeq=#NewAccSeq where AccNo=#AccNo and AccSeq=#AccSeq", SBSConnection3)
command3.Parameters.Add("#AccNo", SqlDbType.Int).Value = reader2("AccNo")
command3.Parameters.Add("#AccSeq", SqlDbType.Int).Value = reader2("AccSeq")
command3.Parameters.Add("#NewAccNo", SqlDbType.Int).Value = CAccNo
command3.Parameters.Add("#NewAccSeq", SqlDbType.Int).Value = CAccSeq
command3.ExecuteNonQuery()
End While
End If
It was working and now gives time out in command3.ExecuteNonQuery()
Any ideas ?
~~~~~~~~~~~
Some information :
There isnt anything that has been changed on network and the app uses local database
The main issue is that even in development environment it donest work anymore
I'll state the obvious - something changed. It could be an upgrade that isn't having the desired effect - it could be a network component going south - it could be a flakey disk - it could be many things - but something in the access path has changed. What other problem indications are you seeing, including problems not directly related to this application? Where is the database stored (local disk, network storage box, written by angels on the head of a pin, other)? Has your system administrator "helped" or "improved" things somehow? The code has not worn out - something else has happened.
Is it possible that this query has been getting slower over time and is now just exceeded the default timeout?
How many records would be in the acc table and are there indexes on AccNo and AccSeq?
Also what version of SQL are you using?
How long since you updated statistics and rebuilt indexes?
How much has your data grown? Queries that work fine for small datasets can be bad for large ones.
Are you getting locking issues? [AMJ] Have you checked activity monitor to see if there are locks when the timeout occurs?
Have you run profiler to grab the query that is timing out and then run it directly onthe server? Is it faster then? Could also be network issues in moving the information from the database server to the application. That would at least tell you if it s SQl Server issue or a network issue.
And like Bob Jarvis said, what has recently changed on the server? Has something changed in the database structure itself? Has someone added a trigger?
I would suggest that there is a lock on one of the records that you are trying to update, or there are transactions that haven't been completed.
I know this is not part of your question, but after seeing your sample code i have to make this comment: is there any chance you could change your method of executing sql on your database? It is bad on so many levels.
Perhaps should you set the CommandTimeout property to a higher delay?
Doing so will allow your command to wait a little longer for the underlying database to respond. As I see it, perhaps are you not letting time enough for your database engine to perform all what is required before creating another command to perform your update.
Know that the SqlDataReader continues to "SELECT" while feeding the in-memory objects. Then, while reading, you require your code to update some other table, which your DBE just can't handle, by the time your SqlCommand requires, than times out.
any chances of a "quotes" as part of the strings you are passing to queries?
any chances of date dependent queries where a special condition is not working anymore?
Have you tested the obvious?
Have you run the "update Acc Set AccNo=#NewAccNo,AccSeq=#NewAccSeq where AccNo=#AccNo and AccSeq=#AccSeq" query directly on your SQL Server Management Studio? (Please replace the variables with some hard coded values)
Have you run the same test on another colleague's PC?
Can we make sure that the SQLConnection is working fine. It could be the case that SQL login criteria is changed and connection is getting a timeout. It will be probably more helpful if you post the error message here.
You can rewrite the update as a single query. This will run much faster than the original query.
UPDATE subquery
SET AccNo = NewAccNo, AccSeq = NewAccSeq
FROM
(SELECT AccNo, AccSeq,
DENSE_RANK() OVER (PARTITION BY AccNo ORDER BY AccNo) NewAccNo,
ROW_NUMBER() OVER (PARTITION BY AccNo ORDER BY AccDate, AccSeq)
+ 10000 NewAccSeq
FROM Acc) subquery
After HLGEM's suggestions, I would check the data and make sure it is okay. In cases like this, 95% of the time it is the data.
Make sure disk is defragged. Yes, I know, but it does make a difference. Not the built-in defragger. One that defrags and optimizes like PerfectDisk.
This may be a bit of a long shot, but if your entire application has stopped working, have you run out of space for the transaction log in your database? Either it's been specified to an absolute size, and that has been reached, or your disk is just full.
May be your tables include more information, and defined SqlConnection.ConnectionTimeout property value in config file with little value. And this value isn't necessary to execute your queries.
you can trying optimize your queries, and also rebuilt indexes.
I have an SSIS package that is refreshing SSAS cube partitions. Each partition is a SQL query running against Teradata. I am using "NET data provider for Teradata" in the SSIS package. The SSAS cube is using "Teradata.Client.Provider". Any particular query executes just fine. However, after 5-10 iterations, I get a SESSION ABORT. After some investigation I found out that all queries are using in the same session:
sel * from DBC.DBQLogTbl where sessionid = 123456
This query returns multiple rows with queries from the loop. Each query by itself does not exceed the CPU AMP threshold, however combined AMP usage exceeds the threshold.
I have configured the connection strings in SSIS and SSAS as following:
SSAS: Connection Timeout=180;Authentication Mechanism=LDAP;Response Buffer Size=64000;User Id=***;Data Source=my.production.server;Persist Security Info=True;Session Character Set=UTF16;Connection Pooling=False;Connection Pooling Timeout=15;Command Timeout=900
SSIS: Data Source=my.production.server;User Id=***;Authentication Mechanism=LDAP;Persist Security Info=True;Session Character Set=UTF16;Connection Pooling=False;
I have disabled parallel execution on the cube. I have disabled the connection pooling as you can see from the connection string. I have set "Maximum number of connections" to 1 on the cube.
Any ideas on how I can force each query to have its own session on Teradata?
Update
After some investigation, I am pretty sure there is a bug hidden somewhere in the cube or database driver. The cube just ignores the
Connection Pooling=false;
parameter and executes each SQL command in the same session. So I've looked into how the driver handles pooling. According to the documentation, the connection string is used as a key when storing a connection resource in the pool. Therefore if you supply a different connection string the driver handles such case as "new connection" and does not use the one already existing in the pool. Now I have a script task after each iteration that "shuffles" the parameters of a given connection string and updates the connection on the cube. This is definitely a hack and I do not recommend this as a solution but desperate times call for desperate measures...
string dcs = #"Connection Timeout=180;Authentication Mechanism=LDAP;Response Buffer Size=64000;User Id=***;Data Source=my.production.server;Persist Security Info=True;Session Character Set=UTF16;Connection Pooling=False;Connection Pooling Timeout=15;Command Timeout=900";
Random r = new Random();
var shuffled = dcs.Split(';').OrderBy(x => r.Next()).ToArray();
var newCs = string.Join(";", shuffled);