[.NET]Sql Connectie timed out

[TeeDee]

Op dit moment ben ik al ruim een dag een Forms (C#) applicatie aan het debuggen die sinds de jaarwisseling niet meer correct werkt. Op één of andere gekke manier gooit deze een timeout exceptie als ik een record wil updaten in een SQL 2000 Server.

De werking is als volgt:
Er staan 2 buttons. Button1 "Count Open Records" en Button2 "Process Open Records".

Button1 voert een Count op de view "view_GetOpenRecords" en Button2 loopt door de dataset heen en schrijft bepaalde zaken in een textfile weg en vervolgens een update van het record.
Zodra Button1 uitgevoerd is (+/- 1 seconde), is het gebruikelijk om daarna meteen Button2 uit te voeren.

Button1 voert zijn werk gewoon netjes uit maar bij Button2 krijg ik een timeout exception in een method ("UpdateRecord") welke aangeroepen wordt per record:

code:

System.Data.SqlClient.SqlException: Timeout expired.
The timeout period elapsed prior to completion of the operation or the server is not responding.
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()

Ik zit er nu al een poosje mijn hoofd over te breken maar ik heb geen flauw idee meer waar dit aan kan liggen.

Wat heb ik gedaan/bekeken:
- Beide Methods maken gebruik van dezelfde Connectionstring.
- De SQL 2000 server heeft op z'n hoogst 50 open user connections.
- De Connectionstring is goed anders werkt Button1 ook niet
- De Timeout op de SQL server is vziw weet nog default (30 sec?)
- Tig keer door de Method Update gestepped, en iedere keer op "ExecuteNonQuery" komt de timeout
- De SQL Query is

SQL:

update tbl_Rec set proces = 1, procesDatum = '20070103' where RecordId = 2800241

- Daar het sinds de jaarwisseling is, dacht ik aan een datum probleem, maar de datum wordt in het ISO format in de db geplaatst en vziw heeft deze geen known bugs met het jaar 2007
Hetgeen wat ik nog wil doen is de SQL query omschrijven met parameters, maar ik zie niet in waarom dit met een Timeout exceptie zou moeten komen.

Ik heb werkelijk waar geen idee meer waar ik dit nu in moet zoeken.

[gorgi_19]

Heb je al Profiler er tegenaan gegooid en kijkt of hij blijft bokken op het uitvoeren van het SQL Statement of dat deze min of meer in een 'queue' wordt geplaatst?

[TeeDee]

Ik heb zojuist de hele handel nog een keer doorgelopen en nu met de Profiler erbij. De DBA is er niet, maar als ik er een "standaard" trace aanhang dan zou ik in principe voldoende informatie moeten krijgen?

Als ik zo de tijden bekijk, dan gaat er niks mis.

[whoami]

sp_locks eens uitvoeren, en zien of dat betreffende record niet gelocked is
Het zou kunnen dat een ander process die row / table / page / extent gelocked houdt, en dan wacht je ander statement tot wanneer die lock vrijgegeven is...

[TeeDee]

Locks by Process: 1 op MSDB
Locks by Objects: allen op een DB voor een website.

[whoami]

Ja, daar weet je niet veel mee.
Als je sp_locks uitvoert, dan zie je welke processen er welke objecten gelocked hebben, en of dat locks op table, page, of extent niveau zijn.

[TeeDee]

Okay, ik heb (begreep je niet goed) sp_lock uitgevoerd. De DB heeft een spid van 93, en deze zie ik nergens in de uitvoer van sp_lock terugkomen.

code:

93  47  629577281   1   PAG 1:226               IX  GRANT
93  47  629577281   0   TAB                     IX  GRANT
93  47  629577281   1   KEY (1800a435d44a)      X   WAIT
95  1   85575343    0   TAB                     IS  GRANT

Dit kwam eruit tijdens het debuggen.

Edit: ik heb de query ook meteen maar even omgeschreven zodat er netjes met parameters gewerkt wordt, alleen, zoals ik al dacht, lost dit niet het probleem op.

[ Voor 63% gewijzigd door TeeDee op 03-01-2007 10:44 ]

[whoami]

Blijkbaar is er wel een process / user (47) die een bepaald object locked (exclusief).
Voer eens sp_who uit, en kijk eens wie 47 is.
Kijk ook eens welk object hij locked :

code:

select object_name (629577281)

[TeeDee]

Ik hoop dat ik het goed begrijp:

sp_who: nergens een proces 47 te vinden.
In sp_who zie ik ook nergens iets van een blk op true staan.

Als ik "select object_name (629577281)" uitvoer dan krijg ik als resultaat: tbl_Rec.

[whoami]

Sorry, ik heb gemist. Doe sp_who, en kijk of er een spid voorkomt dat ook gelist is in de resultaten van sp_lock. In jouw geval is het dus 93

[TeeDee]

Hmm, het spid is inmiddels gewijzigd naar 90 (kan dat???).

sp_lock
Daar krijg ik nu iets van > 200 resultaten bij spid 90. Dat kan kloppen want in de "view_GetOpenRecords" heb ik 216 openstaande records.

sp_who
Bij spid 90 krijg ik netjes de naam van mijn workstation te zien.

code:

90  0   runnable    webuser WS704       TabelNaam   0       SELECT

En na dat de exception gegooid is:

code:

92  0   sleeping      webuser   WS704   90      TabelNaam   UPDATE          
93  0   sleeping      webuser   WS704   0       TabelNaam   AWAITING COMMAND

[ Voor 20% gewijzigd door TeeDee op 03-01-2007 11:27 ]

[whoami]

Ja , dat kan. Ik had verwacht dat er ergens een proces was blijven hangen, en dan kon je het gewoon killen.
Echter, het lijkt alsof je jezelf blijft locken.

[TeeDee]

Zou het komen door dat ik aan het debuggen ben?

Het vreemde is dat deze applicatie 15 december voor het laatst gebruikt is zonder problemen, en nu, na de jaarwisseling wel problemen geeft.

edit
Nou ja, schiet mij maar in een kerstboom. Ik heb de server een schop gegeven, VS.net herstart, het project op Release gezet en nu zonder problemen alles weer aan de praat.

[ Voor 32% gewijzigd door TeeDee op 03-01-2007 13:23 ]