När jag uppdaterar en tabell via query analyzern så blir det något fel i den tabellen jag försöker uppdatera. Felet kommer både då jag kör en vanlig UPDATE och via sparade procedurer.

Felet visar sig som att jag får timeout när jag försöker lista tabellen sen i managern, och det är bara för den tabellen jag uppdaterade, resten av tabellerna fungerar klockrent.

Efter ca 5-10 min brukar tabellen kunna visas igen, dock uppdaterades inte den utan har kvar de gamla värdena.

Detta gäller bara på vissa sql servrar. Ansluter jag via terminal server mot den och uppdaterar i serverns manager fungerar det som vanligt, men inte när jag kör från min klient.

Har funderat på om det kan vara något nätproblem men är inte riktigt säker...

Vad är det för fel du får när du kör update via query analyzern?

Testa att köra sql profiler under tiden du försöker göra en update så ser du den faktiska frågan som fösöker köras. Den frågan kan du kopiera och klistra in i query analyzer och se vad som händer när du försöker köra den.

Låter som låsningsproblem.

Använder du triggrar ?
Och låter i såna fall en trigger att dra igång en annan ?

/Johan

Jag får i query analzern att informationen har uppdaterats, typ " 1 row success updated" eller vad det nu står. Så den verkar ju uppdatera den.

Nej inga triggers, men detta borde inte vara felet ändå, eftersom det går bra då jag kör på servern lokalt.
Det är bara när jag kör på min dator som felet uppstår.

Ok men då vet du att den blivit uppdaterad.

Du kör inga transaktioner? Du kan av misstag göra en rollback efter att raden är uppdaterad.

I query analyzer: Gör en select fråga på just den uppdaterade raden direkt efter update och se vad det är frågan verkligen har uppdaterat.

Kan man få se hur frågan ser ut?

Funkar managern alltid då ?

Det är inte nåt brandväggs-kör ?

Att svaret inte kommer till din klient ?

/Johan

Frågan ser ut ungefär så här:

UPDATE User SET Password = pwdencrypt(@Password) WHERE UserID = @UserID
(Det är alltså i en sparad procedur, men ingen transaktionshantering finns, typ BEGIN TRANS... osv)

Samma fel har hänt även när jag har uppdaterat värden i managern direkt (alltså när man visar raderna i en tabell)

Vill inte köra frågan nu eftersom felet då kommer göra att användarna inte kommer att kunna logga in.

Brandvägg används och då undrar jag om det kan vara där felet är...
Jag kommer åt databasen och allt som vanligt, men är det något som kan spärra just updateringarna i en brandvägg? Det är en packet filtering brandvägg.
Finns andra användare som kör på samma sätt som jag gör, men har inte samma problem.

Jag har stött på liknande problem när man haft en transaktion öppen, t.ex. om man i något tidigare anrop av någon anledning missat att göra commit eller rollback. Testa därför att göra en COMMIT TRANSACTION direkt efter insert-satsen. Har man en transaktion öppen så kommer det verka som om raden kommit in om man gör en select direkt efter insert-satsen, men när man stänger sessionen så kan en implicit rollback göras, och alla ändringar går förlorade.