Excel einlesen mit einer bdpConnection

[diComm]

Bin gerade dabei mit Delphi2005 eine WinForm Applikation zu erstellen, die Daten aus verscheidenen Datenbanken wie auch aus Excel lesen soll und in eine andere beliebige Datenbank schreiben soll.

der Teil mit den Datenbanken klappt auch ganz prima, allerdings schaffe isch es nicht, über die bdpConnection auf eine Exceldatei zuzugreifen.

Kennt jemand den benötigten Connectionstring oder ist das Grundsätzlich nicht möglich?

[Treffnix]

Ging sowas denn mit älteren Delphi-Versionen? Habs nie versucht, weil ich überhaupt nicht auf die Idee gekommen wäre, aber es würde mich wundern.

Excel ist eine Tabellenkalkulation, keine Datenbank. Nichtmal annähernd. Wenn du auf Excel zugreifen willst, geht das über OLE. Allerdings wirst du auch so nicht mit Datensätzen arbeiten können, sondern die einzelnen Excelsheets parsen müssen.

[diComm]

Mit ADOConnection war es möglich, Excel Dateien wie Datenbanken zu behandeln und sogar SQL Befehle waren möglich.

[Bernhard Geyer]

Also mit dem OleDBProvider und Zugriff auf den "alten" JET-OLEDB-Provider sollte es auch noch unter D2005 gehen. Aber ob die BDPConnection das auch kann? Darauf würde ich nicht wetten.

[Robert_G]

Ich weiß nicht, wie oft ich es noch predigen muss...
Schmeiß den BDP am besten gleich aus der ToolPalette, das Ding bringt dir rein gar nichts, was eine überlegte Klassenstruktur nicht 100-mal besser kann.
ein ADO.Net Provider verwendet Klassen, die bestimmte Interfaces implementieren müssen, das heißt: Wenn du eine Instanz IRGENDEINER connection bekommst, kannst du damit ALLES erledigen.
Du übergibst deinen Klassen einfach einen Parameter vom Typ System.Data.IDbConnection.
Kleines, sinnbefreites Beispiel:

Code:

void DoSomething(IDbConnection connection, string sqlStatement)
{
  IDbCommand cmd = conneciton.CreateCommand();
  cmd.CommandText = sqlStatement;
  IDbDataReader rdr = cmd.ExecuteReader();
  while(rdr.Read())
  {
    ...
  }
}

btw: Ich kann da sniper ( ) nur Recht geben würde und sogar noch etwas weiter gehen: Wer Excel zur Datenerfassung verwendet sollte fristlos entlassen werden.

[Phoenix]

Zitat von Robert_G:

Schmeiß den BDP am besten gleich aus der ToolPalette, das Ding bringt dir rein gar nichts, was eine überlegte Klassenstruktur nicht 100-mal besser kann.

Erm, passt zwar nicht zum Topic, aber trotzdem:
Mit den normalen ADO.net - Objekten kann ich nicht mal schnell sagen: "Nee, Junge (also meine Software) MSSQL ist zwar schön und gut, aber HIER hats halt nur ne Oracle." - in einer Config ne Oracle eintragen und die Software läuft dann auf der Ora. Dazu muss ich beim normalen ADO.net tatsächlich komplett andere Klassen verwenden und somit meine Software umschreiben (namespaces etc.). Beim BDP nicht.

Oder hast Du mir da einen konkreten Gegenvorschlag?

[diComm]

Tja, unsere Kunden haben eben keine bessere Iddee als irgendwelche Beispieldaten als .xls zu senden, die wir in unsere Datenbanken einchecken müssen...
Auch wenn ich das gerne tun würde, kann ich ihnen nicht befehlen, mir Daten ausschliesslich in Datenbanken zu übermitteln. So etwas würde hier eher zu einer fristlosen Kündigung führen als der unzweckmässige gebrauch von Excel

[Robert_G]

Zitat von Phoenix:

Oder hast Du mir da einen konkreten Gegenvorschlag?

Wie gesagt, arbeite in deinen Assemblies nicht mit den Klassen des Providers sondern nur mit den Interfaces.
Hast du eine Instanz einer IDbConnection (Egal ob es eine OracleConnection, FbConnection,.. ist) kannst du damit alles erzeigen, was du brauchst.

[Bernhard Geyer]

Zitat von Phoenix:

Dazu muss ich beim normalen ADO.net tatsächlich komplett andere Klassen verwenden und somit meine Software umschreiben (namespaces etc.). Beim BDP nicht.

Und werden dadurch auch die SQL-Syntaxunterschiede versteckt? Vermutlich nicht. Und ich habe auch schon Performancevergleiche ADO.NET <-> BDP.NET gesehen, wo BDP.NET sehr alt ausgesehen hat.

Zum Thema zurück:

Alternativen wären auch:

- Einlesen der Excel-Dokumente per OLE/Automation-Interface von Excel.
- Verwenden eines native-Readers wie Flexel.NET von TMS-Software