Und es geht doch!
Problemstellung:
Der Import einer Excel Tabelle in eine SQL Datenbank funktioniert nur
auf 32-Bit Systemen. Auch die Compilereinstellung 'nur für x86'
funktioniert unter SQL 2005 SP3 und SQL2008 SP1 nicht mehr. Egal, wie
man es anstellt: Ein Verbindungsserver lässt sich zwar einrichten,
aber dann kommt obige Fehlermeldung. Auch der Zugriff über
'Openrowset' oder 'Opendatasource' wie unter
http://msdn.microsoft.com/en-us/library/ms179856.aspx beschrieben,
funktioniert nur unter 32-Bit Windows und 32-Bit SQL-Server.
Microsoft weigert sich beharrlich, in ihren 64-Bit Systemen die
Jet-Engine zu implantieren.
Und es geht doch! Man muss nur einen 'Bug' (bei MSFT ist dies ein
Feature!) im System ausnutzen....
Lösungsweg:
Vorbemerkung: Aufgefallen war mir, dass man mit einer OLEDB
Verbindung unter x64 (Vista, Server 2008, Windows7, Server 2008 R2)
zwar auf Access Datenbanken zugreifen kann, aber nicht mehr auf Excel
Tabellen. Hier kommen unter VS2005 und VS2008 Fehlermeldungen ohne
Ende.
Stundenlang alles probiert und reichlich gegoogelt. Dabei
festgestellt, dass ich wahrlich nicht alleine stehe mit meinem
Problem...
Dann kam Töchterlein und meinte, ich solle mal an den Extended
Properties bei Access etwas fummeln, letztlich sei eine Excel Tabelle
nichts anderes, als eine Access Datenbank, nur abgespeckt.
Dumm geschaut und mal spaßeshalber Excel 8.0 als Extended Properties
unter einer Accessverbindung eingetragen.
Und voilà, man konnte plötzlich die Excel Tabelle an einen
OleDbDataAdapter binden und mit diesem ein DataSet füllen und die
Excel Tabelle in einem DataGriedView anschauen.
Nun gibt es in diversen Foren reichlich Hinweise, wie man Daten aus
einem DataSet in einen zweites DataSet (das dann später an die SQL
Datenbank angebunden wird) überträgt. All diese netten Hinweise
funktionieren leider nur auf 32-Bit Systemen...
Wieder stundenlang gegoogelt und gelesen. Töchterlein grinste...
'MSFT kann ODBC nicht ganz sterben lassen, sonst funktioniert kein
Zugriff mehr von nicht Windows Clients auf einen SQL Server'
Exportiere doch einfach Deine Tabelle über eine Ad-Hoc ODBC
Verbindung. Die müsste sich auch unter .NET erstellen lassen'
Folgender Code führte dann zum Ziel:
strSQL = "SELECT * INTO [odbc;Driver={SQL Server};" & _
"Network=DBMSSOCN;WSID=hd-vistax64;Server=HD-VISTAX64;Database=HDAMS2
000;" & _
"trusted_connection=Yes].Excelkurse " & _
"FROM [AlleKurse$]"
'Den obigen String als OLEDB Command (!sic) unter angezeigtem
DataGried ausführen.
Erklärungen zum Code:
' Vistax64 ist der Name des Hosts für den SQL 2008 Server
' HDAMS2000 ist der Name der Datenbank
'Excelkurse ist eine temporäre Tabelle in der obigen Datenbank, die
zu Anfang eines jeden
'Transfers gelöscht werden muss (drop Table Excelkurse), weil Select
* INTO Anweisungen
'versagen, wenn die Import Tabelle auf dem SQL Server bereits
existiert
'AlleKurse$ ist der Name des Sheets in der Excel Tabelle, dessen
Daten benötigt werden
'Unter der OleDb 'Access' Verbindung (mit Extended Properties =
Excel 8.0)
' ändert VS2008 aber diesen Namen *eigenmächtig* auf _AlleKurse_
' Alternativ kann man statt hd-vistax64 auch Local oder .\SQLEXPRESS
eintragen, damit die
'spätere Anwendung besser übertragbar wird. Oder man fügt diesen
String in die
'Anwendung.exe.config Datei ein, damit spätere Nutzer die
Datenanbindung anpassen können
Vielleicht ist der obige Hinweis ja dem ein oder anderen
Datenbankprogrammierer unter .NET hilfreich.
G.-J.
Problemstellung:
Der Import einer Excel Tabelle in eine SQL Datenbank funktioniert nur
auf 32-Bit Systemen. Auch die Compilereinstellung 'nur für x86'
funktioniert unter SQL 2005 SP3 und SQL2008 SP1 nicht mehr. Egal, wie
man es anstellt: Ein Verbindungsserver lässt sich zwar einrichten,
aber dann kommt obige Fehlermeldung. Auch der Zugriff über
'Openrowset' oder 'Opendatasource' wie unter
http://msdn.microsoft.com/en-us/library/ms179856.aspx beschrieben,
funktioniert nur unter 32-Bit Windows und 32-Bit SQL-Server.
Microsoft weigert sich beharrlich, in ihren 64-Bit Systemen die
Jet-Engine zu implantieren.
Und es geht doch! Man muss nur einen 'Bug' (bei MSFT ist dies ein
Feature!) im System ausnutzen....
Lösungsweg:
Vorbemerkung: Aufgefallen war mir, dass man mit einer OLEDB
Verbindung unter x64 (Vista, Server 2008, Windows7, Server 2008 R2)
zwar auf Access Datenbanken zugreifen kann, aber nicht mehr auf Excel
Tabellen. Hier kommen unter VS2005 und VS2008 Fehlermeldungen ohne
Ende.
Stundenlang alles probiert und reichlich gegoogelt. Dabei
festgestellt, dass ich wahrlich nicht alleine stehe mit meinem
Problem...
Dann kam Töchterlein und meinte, ich solle mal an den Extended
Properties bei Access etwas fummeln, letztlich sei eine Excel Tabelle
nichts anderes, als eine Access Datenbank, nur abgespeckt.
Dumm geschaut und mal spaßeshalber Excel 8.0 als Extended Properties
unter einer Accessverbindung eingetragen.
Und voilà, man konnte plötzlich die Excel Tabelle an einen
OleDbDataAdapter binden und mit diesem ein DataSet füllen und die
Excel Tabelle in einem DataGriedView anschauen.
Nun gibt es in diversen Foren reichlich Hinweise, wie man Daten aus
einem DataSet in einen zweites DataSet (das dann später an die SQL
Datenbank angebunden wird) überträgt. All diese netten Hinweise
funktionieren leider nur auf 32-Bit Systemen...
Wieder stundenlang gegoogelt und gelesen. Töchterlein grinste...
'MSFT kann ODBC nicht ganz sterben lassen, sonst funktioniert kein
Zugriff mehr von nicht Windows Clients auf einen SQL Server'
Exportiere doch einfach Deine Tabelle über eine Ad-Hoc ODBC
Verbindung. Die müsste sich auch unter .NET erstellen lassen'
Folgender Code führte dann zum Ziel:
strSQL = "SELECT * INTO [odbc;Driver={SQL Server};" & _
"Network=DBMSSOCN;WSID=hd-vistax64;Server=HD-VISTAX64;Database=HDAMS2
000;" & _
"trusted_connection=Yes].Excelkurse " & _
"FROM [AlleKurse$]"
'Den obigen String als OLEDB Command (!sic) unter angezeigtem
DataGried ausführen.
Erklärungen zum Code:
' Vistax64 ist der Name des Hosts für den SQL 2008 Server
' HDAMS2000 ist der Name der Datenbank
'Excelkurse ist eine temporäre Tabelle in der obigen Datenbank, die
zu Anfang eines jeden
'Transfers gelöscht werden muss (drop Table Excelkurse), weil Select
* INTO Anweisungen
'versagen, wenn die Import Tabelle auf dem SQL Server bereits
existiert
'AlleKurse$ ist der Name des Sheets in der Excel Tabelle, dessen
Daten benötigt werden
'Unter der OleDb 'Access' Verbindung (mit Extended Properties =
Excel 8.0)
' ändert VS2008 aber diesen Namen *eigenmächtig* auf _AlleKurse_
' Alternativ kann man statt hd-vistax64 auch Local oder .\SQLEXPRESS
eintragen, damit die
'spätere Anwendung besser übertragbar wird. Oder man fügt diesen
String in die
'Anwendung.exe.config Datei ein, damit spätere Nutzer die
Datenanbindung anpassen können
Vielleicht ist der obige Hinweis ja dem ein oder anderen
Datenbankprogrammierer unter .NET hilfreich.
G.-J.