SQL Server Tabellendaten lassen sich nicht ändern

[Frischmilch]

Ich habe ein seltsames Problem:

Ich habe eine SQL Server 2005 Datenbank, auf die ich wärend der Entwicklung gerne mit dem Server Management Studio zugreifen möchte (oder auch mit dem VS2005, wobei das Problem bleibt).
Normalerweise bin ich es gewöhnt, die Daten einer Tabelle direkt in der Tabellenansicht ändern zu können. Das funktioniert aber nicht. Stattdessen kommt ein freundlicher Hinweis, dass sich die Zeile seit dem letzten Aufruf geändert haben soll, was jedoch nicht der Fall ist. Geb ich stattdessen ein SQL Kommando händisch ein, wird dieses korrekt ausgeführt. Auf dauer ist mir das aber zu mühselig, wozu hab ich sonst so ein Tool.

Ich denke, dass etwas an der DB Einstellung verbogen sein muss. Das Problem besteht seitdem ich auf Vista x64 umgezogen bin. Auf Win XP Pro (32bit), gabs keine Probleme. Ich denke dass es eher unwahrscheinlich ist, dass es an den Triggern liegt, welche DB Einträge erzeugen? (Wärend des "manuellen" bearbeiten einer Tabelle hat natürlich nix getriggert, sonst könnt ichs ja verstehen, außerdem gabs die auch schon auf XP).

Ein weiteres Problem, welches ich damit in Zusammenhang bringe, besteht darin, dass eine INSERT Anweisung in zusammenhang mit ExecuteNonQuery() 0 liefert, obwohl eine Zeile eingetragen wurde. Die Anweisung läuft ganz plump ab, ohne eine (eigene) StoredProcedure.

Für Hinweise wäre ich sehr dankbar.

[hwoess]

Einen PrimayKey hast du aber schon auf der Tabelle?
Und was heisst

"Wärend des "manuellen" bearbeiten einer Tabelle hat natürlich nix getriggert, ..."

entweder hängt ein Trigger an der Tabelle oder nicht. Und wen einer dran hängt und nicht deaktiviert wurde, dann schlägt der auch beim "manuellen" Bearbeiten zu.

bye,
Helmut

[Frischmilch]

Also gut, dann hab ich mich wohl etwas unverständlich ausgedrückt.

1. Ich hab versucht möglichst alle Antworten für welche man 2 sec. benötigt im Keim zu ersticken. Ungeschickt, dass ich nicht erwähnt hatte, dass es einen Primary-Key. Aber zur Erinnerung: Es hat schon einmal funktioniert. Unter XP, auch da benötigte man schon Primary-Keys. Sorry für soviel agression, aber mich nervt das Problem schon ein weilchen und es ist ja nicht so, dass ich so gar keine Ahnung davon habe.

2.

Wärend des "manuellen" bearbeiten einer Tabelle hat natürlich nix getriggert, ...

Ist wohl etwas unklar formuliert gewesen. Ich meinte damit, dass wärend ich ein Eintrag in einer Tabelle ändern wollte und es zu diesem Fehler kam, kein Triggerereignis ausgelöst wurde. Der Wert wurde also nicht durch einen Trigger geändert. Nur falls jemand auf diese Idee des Problems hätte kommen können. Allerdings bin ich mir nicht sicher, inweit noch andere Abhängigkeiten bestehen.

[hwoess]

Das mit der PK hätte ja sein können, dass er mal wegen irgendwas kurz entfernt wurde und dass man dann vergaß, ihn wieder anzulegen.
Ansonsten ein Sch**problem, hatte ich vor langer, langer Zeit auch schon mal, kann mich aber leider nicht mehr erinnern, was der Grund war. So könnte ja auch eine falsche MDAC-Version Schuld sein oder irgendwelche Treiber passen nicht zusammen ... aber alles nur geraten, einen konkreten Tipp kann ich dir im Moment leider auch nicht geben.

bye,
Helmut

[Ralf Jansen]

dass eine INSERT Anweisung in zusammenhang mit ExecuteNonQuery() 0 liefert, obwohl eine Zeile eingetragen wurde

Hört sich so an als hättest du in einem Trigger mit SET NOCOUNT gearbeitet aber am Ende ein SET NOCOUNT OFF vergessen oder du hast es nicht vergessen und es ist ein INSTEAD OF Trigger . Das würde auch erklären warum du aus dem Management Studio nicht mehr in der Tabellenansicht updaten kannst, denn hier wird darauf getestet ob du auch genau 1 Zeile geändert hast.

[Frischmilch]

Danke für bisherige Unterstützung.
Das Problem mit dem NOCOUNT gabs tatsächlich. Allerdings hat das keine Auswirkungen auf mein eigentlichs Problem gehabt. Es handelt sich auch nicht um ein INSTEAD OF Trigger sondern um ein AFTER UPDATE.

EDIT:
Jetzt hab ich zwar NOCOUNT OFF im Trigger, jedoch bekomme ich noch immer einen falschen Returnwert bei ExecuteNonQuery(). Allerdings muss ich mich korrigieren, er war nie 0 sondern -1. Wo könnts da krachen? Ich bin weiterhin der Meinung es liegt an der DB..

[Frischmilch]

So noch ein abschließendes Posting mit der Lösung des Problems:
Ausschlaggebend war zwar so eine NOCOUNT Eigenschaft, jedoch war diese Einstellung in den Verbindungseigenschaften des SQL-Servers eingestellt. Das sich dadurch Probleme ergeben, weiß selbst Microsoft, hat aber wohl noch nix dagegen unternommen. Um den Fehler zu beheben sollte man folgendes Prüfen:
Im Server Management Studio einen rechtsklick auf das betroffene Server-Objekt machen und "Eigenschaften" aufrufen, dort die Seite "Verbindungen" wählen und unter Standardverbindungsoptionen prüfen, ob eine Haken bei "keine Anzahl" gesetzt ist. Wenn dies der Fall ist, diesen Haken löschen. Das Problem sollte damit gelöst sein.

Dazu gibts auch folgenden Hilfe Eintrag bei Microsoft:
Microsoft Support