Seltsames Problem bei der Konvertierung des SQL Server-Typs

Dies ist aufgrund der Datentyppriorität vollständig vorhersehbar und zu erwarten

Dafür wird die UI-Spalte auf decimal(25,0)

where UI = 2011040773395012950010370

Dieser ist fast richtig. Die rechte Seite ist varchar und wird in nvarchar geändert

where UI = '2011040773395012950010370'

Das ist wirklich korrekte Version, bei der beide Typen gleich sind

where UI = N'2011040773395012950010370'

Es werden Fehler aufgetreten sein, da die UI-Spalte jetzt einen Wert enthält, der nicht in Dezimalzahl (25,0) umgewandelt werden kann.

Einige unabhängige Anmerkungen:

• Wenn Sie einen Index für die UI-Spalte haben, würde er in der ersten Version wegen des erforderlichen impliziten CAST ignoriert werden
• benötigen Sie Unicode, um numerische Ziffern zu speichern? Es gibt einen ernsthaften Overhead mit Unicode-Datentypen in Speicher und Leistung
• Warum nicht char(25) verwenden oder nchar(25) sind Werte immer feste Länge? Ihre Abfragen verwenden zu viel Speicher als Optimierer geht von einer durchschnittlichen Länge von 128 Zeichen aus, basierend auf nvarchar(256)

Bearbeiten, nach dem Kommentar

Gehen Sie nicht davon aus, „warum funktioniert es manchmal“, wenn Sie es nicht wissen dass es funktioniert

Beispiele:

• Der Wert hätte gelöscht und später hinzugefügt werden können
• Eine TOP-Klausel oder SET ROWCOUNT könnte bedeuten, dass der anstößige Wert nicht erreicht wird
• Die Abfrage wurde nie ausgeführt, daher kann sie nicht fehlschlagen
• Der Fehler wird stillschweigend von einem anderen Code ignoriert?

Bearbeiten Sie 2 für hoffentlich mehr Klarheit

Chatten

gbn:

Zufällig:

gbn

Wie Tao erwähnt , ist es wichtig zu verstehen, dass eine andere Person, die nicht verwandt ist, die Abfrage unterbrechen kann, selbst wenn diese in Ordnung ist.