ADODB Timout on EXECUTE for MSSQL 2000 Database

>>Can anyone tell me why this times out? <<
Because the INSERT query is taking longer than the default 30 seconds.

If you feel you have optimized the query, your hardware and network as much as possible, than you will have to resort to increasing the timeout, as in:

dim cnn, rs
dim sQry, sSqlIns

Set cnn = CreateObject("ADODB.Connection")
Set rs = CreateObject("ADODB.Recordset")

Cnn.Open "Provider=sqloledb;Data Source=10.20.112.186;Network Library=DBMSSOCN;Initial Catalog=UAT;User ID=sa;Password=xxx;"
cnn.CommandTimeout = 300           ' 5 minutes.
cnn.execute "insert into UAT21.STORERCONFIG(STORERKEY,STORERCONFIGKEY,DESCRIPTION,FLAG) VALUES('001','ALDUPIDSTO','IF TURNED ON WILL ALLOW DUPLICATE IDS DURING GEO RECEIPTS','N')"

You may want to look at the query again.  It's a simple insert of one value.  There is nothing to optimize.  I can run the same query directly in the database and it inserts just fine in less than a second.  As for the connection, I can use the same connection to run a select and it returns just fine, so I don't think it is an issue with the connection object.

I should have also noted, that I've increased the timeout more than enough to feel it's something else.  I guess you are essentually correct that it's "timing out", perhaps my question should be what do you think is causing it to timeout.  I was thinking that it may have something to do with the schema being specified in the insert and ADODB not liking that.

Than I am afraid I have no idea.

No worries.  Thanks for trying...Ken

Perhaps try declaring your connection type at compile time:

dim cnn as ADODB.Connection
set cnn = new ADODB.Connection
Cnn.Open "Provider=sqloledb;Data Source=10.20.112.186;Network Library=DBMSSOCN;Initial Catalog=UAT;User ID=sa;Password=xxx;"
cnn.
cnn.execute "insert into UAT21.STORERCONFIG(STORERKEY,STORERCONFIGKEY,DESCRIPTION,FLAG) VALUES('001','ALDUPIDSTO','IF TURNED ON WILL ALLOW DUPLICATE IDS DURING GEO RECEIPTS','N')"

   

Maybe that's part of the problem.  This is just vbscript running in windows scripting host.

Than the following is not an option:
dim cnn as ADODB.Connection
set cnn = new ADODB.Connection

Good point, but the syntax is actually:

Set cnn = CreateObject("ADODB.Connection")
Set rs = CreateObject("ADODB.Recordset")

I think dqmq retyped the other syntax in their suggestion.  

My connection is good.  Any recordsets come back fine.  It's just inserts that fail.

Is there a trigger on that table? If the command works fine then that should be academic - but who know?

What environment are developing/running in? I guess the main difference between running it in SQL and in you development environment is probably the data drivers. What version of ADO are you running?

You also mention about the "Schema", but in SQL 2000 the schema was actually the "Owner", it didn't become the schema until SQL 2005. Again, I doubt that's the problem but might be worth mentioning.

Cheers
Chris

Thanks Everyone.  EddyKt hit the problem.  When I put the port into the connect string, it worked fine.  Why a select would work without the port, but an update willl not is something interesting.  I guess when the rs object wraps the cnn, it provides some defaults that are not in the cnn object.

Thank you everyone!

>>Good point, but the syntax is actually: <<
The syntax dqmq was using was for early binding using Visual Basic, since you are using VBScript that is not an option.

>>Why a select would work without the port, but an update willl not is something interesting. <<
Than it is a network problem and specifically can be solved with the Client Network Utility.

>>I guess when the rs object wraps the cnn, it provides some defaults that are not in the cnn object.<<
Not sure what a recordset has got to do with this.  There is no recordset involved in an Insert statement.

>> >>I guess when the rs object wraps the cnn, it provides some defaults that are not in the cnn object.<<
>> Not sure what a recordset has got to do with this.  There is no recordset involved in an Insert statement.

The reason it is relevant is because in a prior post, network was ruled out because a recordset was returned.  The thought was that if the connect string worked for a recordset, it must work with a cnn.execute also.

>>The thought was that if the connect string worked for a recordset, it must work with a cnn.execute also. <<
I guess you have put that myth to rest now, then.