<Document>

<FileName></FileName>
<FileType></FileType>
<CreatedAt></CreatedAt>
<Data></Data>

</Document>

Das <Data> Feld wurde natürlich mit base64 encoded damit man schön XML reinschreiben und auslesen konnten.

Da der Vortschritt aber auch hier einzug gehalten hat, gibt es jetzt auch hier eine eigene Tabelle mit einem Blob für <Data>. Dabei stellte sich nur die Frage wie man jetzt am besten von base64 auf Blob migriert. Folgenden netten XQuery befehl habe ich hierfür gefunden:

Documents.value(‘xs:base64Binary(/*:Documents[1]/*:Document[1]/*:Data[1])’, ‘varbinary(MAX)’)

English:

One of our customer used XML to save files inside there DB (Sql Server 2005):

<Document>

<FileName></FileName>
<FileType></FileType>
<CreatedAt></CreatedAt>
<Data></Data>

</Document>

The <Data> field was of course base64 encoded to make it easy to read and write XML files form it.

After some progress they managed to save the data into a new table with an Blob field for <Data>, but the tricky part was: how to get the base64 data into the Blob field,… during some research I found the following XQuery command.

Documents.value(‘xs:base64Binary(/*:Documents[1]/*:Document[1]/*:Data[1])’, ‘varbinary(MAX)’)

Wir hatten aber nun das Problem, dass sobald wir unsere Applikation starten wollten, wir immer folgenden ORA-Fehler bekamen:
ORA-12154: TNS:could not resolve the connect identifier specified

Andere 32bit Software konnte aber erfolgreich mit der Oracle-DB kommunzieren…
Am Ende des Arbeitstages hatten wir endlich den Grund des Problems gefunden:
http://blogs.msdn.com/debarchan/archive/2009/02/04/good-old-connectivity-issue.aspx

Zusammengefasst ist es ein Bug im x86 Oracle Client 10.2.0.1 - jedede Art von Klammern (!) im Pfad der zu startenden Applikation verursacht oben genannten Fehler!
Und auf einem x64 Windows werden alle 32bit Applikation standardmässig auf “C:\program files (x86)\…” installiert…

SELECT Top 1 Employees.Country, Employees.LastName, Employees.FirstName, Orders.ShippedDate, Orders.OrderID, "Order Subtotals".Subtotal AS SaleAmount
FROM Employees INNER JOIN
(Orders INNER JOIN "Order Subtotals" ON Orders.OrderID = "Order Subtotals".OrderID)
ON Employees.EmployeeID = Orders.EmployeeID

SELECT Top 1 Employees.Country, Employees.LastName, Employees.FirstName, Orders.ShippedDate, Orders.OrderID, "Order Subtotals".Subtotal AS SaleAmount
FROM Employees INNER JOIN
(Orders INNER JOIN "Order Subtotals" ON Orders.OrderID = "Order Subtotals".OrderID)
ON Employees.EmployeeID = Orders.EmployeeID
WHERE Employees.EmployeeID > 1
and "Order Subtotals".Subtotal > 2490.50

Einmal ist die Subtotal Abfrage im FROM/JOIN Bereich und einmal im WHERE. In diesem Fall liefert der SQL Server tatsächlich das gleiche Ergebnis. Nun ist mir aber bei einem Kunden folgendes passiert: In einer Kundentabelle, werden die Kundendatensätze auch noch versioniert. Es musste auf eine bestimmte Version eines Satzes zugegriffen werden und dazu wurde leider weder ein ORDER BY DESC oder ein zielgerichtetes Abfragen auf die richtige Version des Datensatzes zurückgegriffen, sondern – einfach mit TOP 1 gearbeitet. Im FROM/JOIN Bereich hatte die Abfrage alle Versionen geliefert und daher bei TOP 1 immer die älteste Version. Durch Kopieren in den WHERE Bereich war das Problem dann gelöst. Ich werde versuchen auf Basis der Northwind Datenbank dieses Phenomen nachvollziehbarer zu machen. Aber es war mir jetzt schon wichtig genug das niederzuschreiben.

Entity Framework Learning Guide
MSDN – ADO.NET Entity Framework
MSDN – Samples Entity Framework