Microsoft - Software with special needs

Kategorien: tech Tags: tech SQL MS Access SQL Server Fuckup IT Keys Programmierung ODBC Technik -

Ich darf seit ein paar Jahren ein altes legacy-MS-Access-Projekt pflegen. Ja, das ist eine Strafe und ich weiß nicht womit genau ich sie verdient habe. VB war jedenfalls definitiv in der Stellenbeschreibung auf die ich mich mal beworben hab nicht erwähnt.

Jedenfalls, weil Access alles andere als eine erträgliche Datenbank ist, wurde irgendwann alles an Daten ausgelagert, an einen MS SQL Server und per ODBC wieder in Access eingebunden.

Jetzt sollte man meinen dass wenigstens eine Sammlung reiner Microsoft-Produkte einigermaßen erträglich über ein Microsoft-Protokoll miteinander reden können sollten, aber das ist ein naiver Fehlschluss.

Es gibt so einige Dinge an dieser Konstruktion die mir immer wieder Übelkeit verursachen und ich habe schon etliches an sinnloser Zeit mit Debugging verschwendet wenn mal wieder ein Index im SQL Server anders definiert wurde als Access erwartet und einfach nicht verwendbar war.

Heute hat das Ding mal wieder den Vogel abgeschossen.

Bei einigen Update-Vorgängen lieferte Access wirre Fehlermeldungen, deren Ursache zuerst schwer nachvollziehbar war. Vor allem da die gleichen SQL-Abfragen (nach Ersetzen der Tabellen-Namen, Access verwendet lokale Namen die nicht dem in der DB entsprechen müssen) im SQL Server Management Studio problemlos durchliefen. Auch andere Tools wie MariaSQL hatten kein Problem damit, also schloss ich ein Problem auf Serverseite erstmal aus.

To the debug-Cave!

Also mal kurz angesehen welche Zeilen denn Probleme verursachen könnten, indem ich mir ein paar gefundene Einträge bei denen das auftritt genauer ansehe:

SELECT AngNr, Makler FROM EVT_Angebot WHERE Makler=“foobar”

Total einfach, da kann doch unmöglich irgendwas kaputt… WAS ZUM…?!

8 Resultat-Zeilen, eine entspricht eigentlich nicht dem WHERE-Kriterium

Was will mich hier wieder verarschen? Mal sehen was Managment Studio ausspuckt wenn ich die gleiche Zeile reinwerfe…

Korrektes, erwartetes Ergebnis

OK, das ist also ein Unterschied. Mal sehen wie der Index definiert ist…

AngNr ist der primäre Index für diese Tabelle

Uhh…

SELECT AngNr, Makler FROM dev_Angebot WHERE AngNr=25195

Oh Scheiße!

Mehrere Ergebnisse für das letzt Query

Ich hoffe das kommt nicht zu oft vor.

SELECT angnr, count(angnr) c   FROM de_angebot GROUP by angnr having count(angnr) > 1 order by c desc

Resultat?

1490 IDs mit mehr als einer Zeile

I DON’T WANT TO LIVE ON THIS PLANET ANYMORE!

Aber… Warum?

Ich weiß nicht wie die DB so zerschossen wurde dass da IDs doppelt vergeben sind. Ich könnte mir vorstellen dass man das vlt. mit IDENTITY_INSERT auf On schaffen könnte.

Jedenfalls holt Access sich bei einem Query erst alle IDs die dem Query entsprechen, zieht dann für jede ID die Zeile und da hier IDs doppelt vergeben sind, nimmt er halt die jeweils erste Zeile die er bekommt.

Ich will auch gar nicht wissen warum das so passiert, noch weniger warum die Dreckskiste das auch bei einem UPDATE tut oder wie auch immer sich irgendwer gedacht hat dass mal eine funktionierende, performante Idee sein sollte.

Geschrieben von: DAT
Nächster Artikel
Klimawandel