ADO.NET und Views in MS SQL
Nach langer Zeit mal wieder ein Kommentar von mir. 
In meinem neuen Job habe ich mittlerweile viel mit Microsoft Produkten wie SQL Server und Visual C# zu tun. Ich muss sagen, dass es nicht annähernd so schlimm ist, wie die meisten Programmierer die ich so kenne immer sagen. Es macht schon fast Spaß. 
Heute stieß ich aber auf ein Problem, welches so richtig zum kotzen war.
Serverseitig setzen wir in einer größeren Server Applikation ADO.Net ein, was eine Abstraktionsebene für den Zugriff auf Datenbanken bereit stellt. Alle Tabellen stehen im Programmcode als Objekt bereit, sodass man auf "echte" SQL Queries in 99% der Fälle verzichten kann.
Über einen Wizard kann man diese Objekte automatisch erzeugen lassen. Man muss hier eigentlich nichts von Hand machen. Problematisch wird es hier, wenn man auf komplizierte Views zugreifen will. Denn ADO.Net verlangt in jeder Tabelle/View einen eindeutigen Primärschlüssel.
In einem komplizierten View mit GROUP BY, DISTINCT oder Subqueries findet ADO.Net keinen Primärschlüssel mehr und verweigert das Erzeugen der Objekte. Tja... Und dann steht man da... *grrr*
Abhilfe schafft hier ein kleiner Hack, der einen Primärschlüssel "ercheatet". Dadurch das man den bei Views sowieso nicht braucht, ist das aber wurscht. Folgendes setzt man als Spalte in das View ein:
ISNULL(CAST(
CASE ROW_NUMBER() OVER (ORDER BY columnNames)
WHEN ROW_NUMBER() OVER (ORDER BY columnNames) THEN
ROW_NUMBER() OVER (ORDER BY columnNames)
ELSE 0
END AS int), 0) AS ID
Der SQL Schnipsel erzeugt eine Spalte mit einer fortlaufenden Nummer, die ADO.Net lustigerweise als Primary Key annimmt. Wieso das so ist: Keine Ahnung. Ich war einfach froh mit einer laufender Server Applikation im Keller nach Hause fahren zu dürfen.
Die Tage wird es bestimmt noch mehr zu .NET und anderen Microsoft-"Verbrechen" geben.
Seid gespannt.
