Mehrteilige Kennung in Microsoft SQL Server

Ich migriere eine SQL Server 6.5-Datenbank auf SQL Server 2012. Die Migration verlief gut, aber eine der Software, die diese Datenbank verwendet, führt eine seltsame Abfrage aus:

UPDATE myTable SET Field1='',Field2=0, a.Field3=14 WHERE Field10=1

Das Problem liegt natürlich bei der Kennung ('a') vor Field3. Es gibt keine Ansichten, Aliase oder Verknüpfungen mit diesem Namen, aber für SQL Server 6,5 ist dies eine gültige Abfrage.

Erinnert sich einer von Ihnen an die Bedeutung dieser Syntax, da ich mit SQL Server 6.5 nicht vertraut bin?

Die Software, die diese Abfrage verwendet, ist eine alte, von der ich keine Quellen habe (und die Firma, die sie erstellt hat, ist jetzt geschlossen ...), daher ist das Ändern der Abfrage keine Option.

Die vollständige Abfrage lautet

UPDATE SituazioneMacchina 
SET DatiSetPointSpediti=''
,   SpedMappa=0
,   NrRichMappa=0
,   DatiSetPoint=''
,   a.IDProduzione=14
WHERE NumMacchina=1

Wenn ich "a.IDProduzione" durch "fasdffas.IDProduzione" ändere, funktioniert die Abfrage weiterhin in SQL Server 6.5

sql-server

— Nicola Cassolato
quelle

Die vollständige Abfrage lautet wie folgt: UPDATE SituazioneMacchina SET DatiSetPointSpediti = '', SpedMappa = 0, NrRichMappa = 0, DatiSetPoint = '', a.IDProduzione = 14 WHERE NumMacchina = 1 Wenn ich "a.IDProduzione" mit etwas wie "fasdffas" ändere .IDProduzione ", die Abfrage funktioniert immer noch in SQL 6.5

— Nicola Cassolato

Wenn die Abfrage wurde UPDATE a SET ... FROM myTable AS a WHERE ..., sollte sie gültig sein, ja?

— Billinkc

Sieht so aus, als ob dies durch 7.0 behoben wurde. Ich kann diese Syntax nicht akzeptieren. 4.21 ist jedoch in Ordnung, wenn der Tabellenalias im Wesentlichen ignoriert wird.

— db2

@ db2 - Sie haben noch 4.21 ausgeführt?

— Martin Smith

@MartinSmith Hat nicht jeder eine 4.21 VM herumgesessen? :)

— db2

Wie Sie sagen, macht die Abfrage keinen Sinn.

Wahrscheinlich nur ein Parser-Fehler in 6.5. Es gibt ein paar ähnlichen anderen Probleme gewesen ORDER BY nonsensealias.somecolumnarbeiteten bis 2005 mit den SQL Server 2000 - Verhalten Wesen

Spaltennamen in der ORDER BY-Klausel werden in Spalten aufgelöst, die in der Auswahlliste aufgeführt sind, unabhängig davon, ob sie qualifiziert sind. Die folgende Abfrage wird beispielsweise fehlerfrei ausgeführt:

USE pubs
SELECT au_fname AS 'FName',
  au_lname AS 'LName'
FROM authors a
ORDER BY a.LName

SQL Server ignoriert das Qualifikationsmerkmal a in der ORDER BY-Klausel und löst den Spaltennamen LName in die Auswahlliste auf.

und es gibt immer noch ein ähnliches Problem für INSERTAnweisungen, bei denen die folgende Syntax akzeptiert wird.

CREATE TABLE nisse(hult int NOT NULL)
go
INSERT nisse(ab.xx.hult)
VALUES(12)
go
DROP TABLE nisse

— Martin Smith
quelle

Danke Martin. Ich habe dieselbe Abfrage in SQL 2008 mit SQL 2000-Kompatibilitätsstufe versucht und sie funktioniert nicht. Vielleicht wurde der Fehler in SQL 2000 behoben. Ich werde noch einen Tag nachforschen und dann Ihre Antwort als akzeptiert markieren.

— Nicola Cassolato

@Nicola query in SQL 2008 with SQL 2000 compatibility levelDies ändert einige Dinge beim Parsen und Tokenisieren, aber es gibt immer noch nur EINE zugrunde liegende Engine, dh es wird die SQL Server 2000-Engine nicht auf magische Weise ausgeführt!

— 6.

Ja Richard, ich weiß das, ich hatte nur gehofft :)

— Nicola Cassolato

@ Martin: Du hattest recht. Es ist ein SQL 6.5-Fehler, der in SQL Server 7.0 behoben wurde. Ich kann dafür sorgen, dass diese Abfrage unter SQL 2000 mit einer Kompatibilitätsstufe von bis zu 65

— funktioniert