Benutzer mit den meisten Antworten
Fehleranalyse UPDATE Befehl

Frage
-
Guten Tag Zusammen
Ich habe eine Tabelle namens Project.
Mit ganz vielen Spalten und Beziehungen z.B. LanguageCode (int). PK ist uniqueidentifier.
Ich weiss nicht wieso, aber plötzlich funktioniert kein UPDATE-Befehl mehr.
z.B: update Project set LanguageCode = 0
Gibt folgenden Fehler zurück: "Meldung 8169, Ebene 16, Status 2, Zeile 1
Fehler beim Konvertieren einer Zeichenfolge in 'uniqueidentifier'."
Das gleiche Schema, verwende ich in einer anderen Datenbank. Dort funktioniert der Befehl einwandfrei.
Nun, ich vermute irgendetwas ist korrupt.
DBCC CHECKTABLE habe ich bereits durchgeführt. Alle Indexe sind neu organisiert, die Tabelle hat keine Trigger.
Wie kann ich herausfinden, wo der Fehler auftritt?
Vielen Dank für Tipps und Lösungen.
Gruss Stefan
Antworten
-
Hallo Leute
Ich hab mir das Ei mal wieder selber gelegt :-S
Der Fehler entstand durch ein falsches Broker Script (.NET SqlDependency mit WHERE-Bedingung) die den Konvertierungsfehler ausgelöst hat.
Sorry das ich eure Zeit in Anspruch genommen habe.
Trotzdem danke und einen schönen Tag wünsche ich euch.
Gruss
--- Stefan Bättig
- Als Antwort markiert stefan.baettig Donnerstag, 12. Juli 2012 10:32
- Bearbeitet stefan.baettig Donnerstag, 12. Juli 2012 10:33
Alle Antworten
-
Hallo Stefan,
bei genau diesem UPDATE Befehl kommt der o.g. Fehler?
Falls ja, kann ich mir eigentlich nur vorstellen, dass da noch ein Trigger auf der Tabelle sitzt, der dann irgendetwas machen möchte, das aber aufgrund eines falschen Werts in der PK Spalte (bspw. NULL, ...) eben auf Fehler läuft. Auch wenn Du schreibst, dass kein Trigger auf der Tabelle liegt, fällt mir grade nichts anderes ein, dass das bewirken könnte.
Gibt es evtl. einen CLR Trigger? Da könnte es sein, dass man den auf der Tabelle selbst nicht sieht, er aber trotzdem zieht.
Probier doch mal, ein SELECT auf die PK Spalte zu machen und die Werte explizit in nvarchar und wieder zurück in uniqueidentifier zu konvertieren.
SELECT CONVERT( uniqueidentifier, CONVERT( nvarchar( 64 ), <Spalte> ) ) FROM <Tabelle>
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
- Bearbeitet Stefan FalzModerator Mittwoch, 11. Juli 2012 15:32
-
Mit ganz vielen Spalten und Beziehungen z.B. LanguageCode (int). PK ist uniqueidentifier.
z.B: update Project set LanguageCode = 0
Fehler beim Konvertieren einer Zeichenfolge in 'uniqueidentifier'."
Hallo Stefan,
Ist das das ganze UPDATE Statement; es würde ja alle Datensätze auf einmal aktualisieren. In der Regel filtert man, wie auf den PK, der hier "zufällig" ein uniqueidentifier wie in der Fehlermeldung ist.
Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing -
Nochmal ein Stefan :-)
Hallo und Danke für dein Tipp, aber das habe ich auch schon probiert. Funktioniert.
CLR-Trigger verwenden wir nicht, und es ist wirklich kein anderer T-SQL Trigger auf dieser Tabelle vorhanden.
Kann man irgendwie nachverfolgen was der SQL-Server im Hintergrund macht? Oder eine detailliertere Fehlermeldung erhalten?
Gruss Stefan
-
Hallo Stefan,
hängt an der Tabelle evtl. ein Trigger dran?
Grundsätzlich gilt: Uniqueidentifier müssen im dort genannten Format (oder binär) sein.
Gruß Elmar
-
hängt an der Tabelle evtl. ein Trigger dran?
Elmar, laut letzten Post vom Op auf Stefan's Nachfrage ja nicht. Allerdings halt auch ich das für die Ursache.
@Stefan, nicht das ich Deine Aussage bezweifele, aber deaktiviere zur Sicherheit mal alle Trigger auf der Tabelle mit dem DISABLE TRIGGER Kommando mit der Option ALL
DISABLE Trigger ALL ON dbo.Project
Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing -
Guten Morgen Leute
Habe DISABLE Trigger ALL ausgeführt, hat nichts gebracht.
Mir ist noch aufgefallen, das wir den Broker in unserer Applikation brauchen.
Nun DISABLE_BROKER hat auch nichts gebracht.
Ich könnte ja das Backup restoren und das Problem so lösen, aber ich will gerne gewappnet sein, falls dies mal bei einem Kunden auftreten sollte.
Bin mit meinem Latein am Ende. Gibt es denn keine Möglichkeit zu untersuchen, was der SQL-Server noch alles im Hintergrund macht und aktualisiert?
Habe sogar mit Visual Studio den Befehl gedebuggt...
Grüsse
Stefan
-
Hallo Stefan,
ich würde mich der Meinung anschließen das da Code läuft.
1. Ist da evtl ein default hinterlegt?
2. Was siehst Du bei den Abhängigkeiten der Tabelle?
3. Schau Dir doch das Create Table Statement welches das Management Studio ausgibt etwas genauer an.
HTH.Grüße Alexander
-
Ich könnte ja das Backup restoren und das Problem so lösen, aber ich will gerne gewappnet sein, falls dies mal bei einem Kunden auftreten sollte.
wenn dies moeglich ist, wuerde ich ein Backup auf einem anderen Server restoren und dort pruefen ob das gleiche Problem auftritt.
wenn es ebenfalls auftritt, weisst Du wenigstens, dass es ein Problem in den Daten und/oder DB Schema ist und nicht einfach korrupte Daten welche nicht gelesen werden koennen. Ueberdies hast Du dann die Moeglichkeit auf diesem Rechner suzkessive Daten auszuschliessen um den fehlerhaften Record(s) zu finden.
hast Du bereits einen ausfuehrlichen/detailierten DB Check ausgefuehrt und geben die verschiedenen Eventlogs und SQL Logs keinen Hinweis auf einen HW-Fehler, I/O Lesefehler etc.?
noch was, wie gross ist eigentlich die DB und wieviele Records sind in der Tabelle ?
Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.
- Bearbeitet Daniel_Steiner Donnerstag, 12. Juli 2012 06:22
-
Hallo Leute
Ich hab mir das Ei mal wieder selber gelegt :-S
Der Fehler entstand durch ein falsches Broker Script (.NET SqlDependency mit WHERE-Bedingung) die den Konvertierungsfehler ausgelöst hat.
Sorry das ich eure Zeit in Anspruch genommen habe.
Trotzdem danke und einen schönen Tag wünsche ich euch.
Gruss
--- Stefan Bättig
- Als Antwort markiert stefan.baettig Donnerstag, 12. Juli 2012 10:32
- Bearbeitet stefan.baettig Donnerstag, 12. Juli 2012 10:33