Builder: Excel Datei per ADO erstellen und in DBGrid laden

[Mordhorst3k]

Hi,

vorweg, ich benutze kein Delphi, sondern C++ Builder 10.3.3 CE. Eine neuere Version gibt es leider nicht.

Ich habe ein Problem beim erstellen einer Excel Datei via ADO. Aktuell verwende ich den OleDB von Access 2010. Da ich .xls / .xlsx / .xlsm einlesen kann, scheinen die ConnectStrings zu funktionieren.

Wenn ich also ADOCommand benutze, funktioniert das erstellen zwar, aber man muss Create Table offensichtlich mit Parameter aufrufen und da wird mir dann ein Header in der Tablle eingefügt, den ich da eigentlich nicht haben will. Löschen geht auch nicht, da ISAM Einschränkung.

Code:

ADOCommand1->CommandText = "Create Table Tabelle1(id integer, name char(80))";

Das habe ich via Google gefunden, das funktioniert, aber da wird mir eben der Header eingefügt. Wenn ich id/name weglasse, gibt es die die Fehlermeldung: "Syntaxfehler in Felddefinition". Möchte eigentlich nur eine frische Tabelle erstellen, ohne Inhalt jeglicher Art, mehr nicht. Anzumerken ist, dass ich selbst kein Excel habe, sondern nur LibreOffice.

Lässt man "Create Table" weg, wird die Datei zwar erstellt, aber beim beenden wieder gelöscht.

Hier mal der Code den ich benutze.

Code:

   ADOConnection1->Connected = false;
   ADOTable1->Active = false;

   AnsiString Provider, Extended, Persist;

   AnsiString FileName = "F:\\test.xls";
   // AnsiString FileName = "F:\\test.xlsx";

   AnsiString DataSource = "Data Source=" + FileName + ";";

   Provider = "Provider=Microsoft.Jet.OLEDB.4.0;";
   Extended = "Excel 8.0;HDR=No;";
   Persist = "Persist Security Info=False;Jet OLEDB:Engine Type=35;";

   // Provider = "Provider=Microsoft.ACE.OLEDB.12.0;";
   // Extended = "Extended Properties=Excel 12.0 XML;HDR=No;";
   // Persist = "Persist Security Info=False;Jet OLEDB:Engine Type=38;";  // mit Type 35 lässt sich Datei in Excel nicht öffnen?? Unbekanntes Dateiformat.

   ADOConnection1->ConnectionString = Provider + DataSource + Extended + Persist;
   ADOConnection1->Connected = true;

   ADOCommand1->CommandText = "Create Table Tabelle1(id integer, name char(80))";

   ADOCommand1->Execute( );

   ADOConnection1->Connected = false;
   ADOConnection1->Connected = true;

   ADOTable1->TableName = "Tabelle1$";
   ADOTable1->Active = true;
   lblCount2->Caption = "Record Count: " + IntToStr( ADOTable1->RecordCount );

   ADOTable1->Active = false;
   ADOTable1->Active = true;

Danke im voraus für mögliche Anregungen.

[Bernhard Geyer]

Ich halte den Ansatz für sehr ungünstig gewählt.
Deine Daten kannst du dir auch ohne ADO/Excel-OLEDB-Verkomplizierung in ein Grid laden.

Und wenn ADO/OLEDB so viel Problem bereitet beim erstellen der Excel-Datei, schreib es doch über die COM-Schnittstelle.
Sollte auch weniger Probleme bereiten als über ADO/OLEDB.

[Mordhorst3k]

Für COM braucht man aber scheinbar Excel, das habe ich aber nicht.

Die Kompomnenten die für Office 2000/XP dabei sind, gehen wohl auch über COM. Wenn ich die EXE mit RTL/Packages kompiliere, Linker-Fehler bekomme. Da man für die Excel braucht, habe ich da nicht weiter rumgemacht.

ADO scheint wohl die einzige Möglichkeit zu sein wie es scheint. Aber im Notfall werde ich einfach etwas cheaten, eine leere Excel-Tabelle machen und diese entweder Binär in eine Unit packen, oder als Resource in die EXE. Beides ist aber recht unsauber und ich bin da kein Fan von, vor allem, weil meine Programmierskills nicht die Besten sind.

Trotzdem danke für deinen Tipp/Rat.

[Delphi.Narium]

ADO ist halt eine Datenbankschnittstelle und hier wird Excel eben als Datenbank "missbraucht". Von daher muss man beim Erstellen, Schreiben, Lesen, Löschen, ... der "Excel"-Tabelle SQL benutzen.

[Papaschlumpf73]

Zitat:

Zitat von Delphi.Narium (Beitrag 1492482)

ADO ist halt eine Datenbankschnittstelle und hier wird Excel eben als Datenbank "missbraucht".

Ich musste gerade daran denken, wie oft Excel in deutschen Büros als Datenbank missbraucht wird. :-)

[Bernhard Geyer]

Zitat:

Zitat von Mordhorst3k (Beitrag 1492481)

Für COM braucht man aber scheinbar Excel, das habe ich aber nicht

Es gibt Komponenten welche das Excel-Dateiformat selbst schreiben.
Kosten jedoch immer ein paar € (bzw. mir ist keine Kostenlose bekannt).

[Mordhorst3k]

Zitat:

Zitat von Delphi.Narium (Beitrag 1492482)

ADO ist halt eine Datenbankschnittstelle und hier wird Excel eben als Datenbank "missbraucht". Von daher muss man beim Erstellen, Schreiben, Lesen, Löschen, ... der "Excel"-Tabelle SQL benutzen.

Als ich SQL probiert habe, kam die Meldung, ISAM unterstützt kein löschen. Vielleicht habe ich es auch falsch gemacht, aber ich habe nichts brauchbares gefunden, was mir bei meinem Problem weitergeholfen hat. Google auch kaum bis wenig hilfreich.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1492485)

Zitat:

Zitat von Mordhorst3k (Beitrag 1492481)

Für COM braucht man aber scheinbar Excel, das habe ich aber nicht

Es gibt Komponenten welche das Excel-Dateiformat selbst schreiben.
Kosten jedoch immer ein paar € (bzw. mir ist keine Kostenlose bekannt).

Für mein kleines privates Projekt (eigentlich ein Tool für einen Freund, der Excel hat, ich aber nicht) lohnt sich das kaufen einer Komponente nicht wirklich.

[Delphi.Narium]

Andere Idee:

Wenn er Excel hat, hat er (vermutlich) auch Access, zumindest dürfte die JetEngine vorhanden sein.

Excel kann auch Tabellen aus Accessdatenbanken lesen (siehe Dateiöffnendialog von Excel und dort die Liste der Dateitypen).

Mit Deinem Programm könntest Du von daher einfach eine Accessdatenbank mit entsprechenden Tabellen nutzen, die kann man dann auch per Excel öffnen.

Weitere Alternative:

Excel kann mit CSV-Dateien umgehen. Über ADO i. V. m. dem passenden (eigentlich immer vorhandenen) ODBC-Treiber kann man ebenfalls auf CSV-Dateien zugreifen und diese dann in 'nem DBGrid anzeigen.

Ob's für Deine Aufgabenstellung geeignet ist, vermag ich nicht zu sagen, aber Versuch macht Klug.

[Andreas13]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1492485)

Zitat:

Zitat von Mordhorst3k (Beitrag 1492481)

Es gibt Komponenten welche das Excel-Dateiformat selbst schreiben. Kosten jedoch immer ein paar € (bzw. mir ist keine Kostenlose bekannt).

Es sieht so aus, daß

Delphi-Quellcode:

CnXlsWriter.pas

im Verzeichnis

CnVCL-master\Source\DbReport\

von CnPack VCL Components https://github.com/cnpack/cnvcl Excel-Files schreiben kann. Es soll sowohl für Delphi als auch für C++ Builder geeignet sein.

Gruß, Andreas

[Andreas13]

Sorry, ich sehe gerade, daß ohne Excel mit dem CnPack nichts läuft...:oops:
Andreas

[Mordhorst3k]

Zitat:

Zitat von Delphi.Narium (Beitrag 1492668)

Andere Idee:

Wenn er Excel hat, hat er (vermutlich) auch Access, zumindest dürfte die JetEngine vorhanden sein.

Excel kann auch Tabellen aus Accessdatenbanken lesen (siehe Dateiöffnendialog von Excel und dort die Liste der Dateitypen).

Mit Deinem Programm könntest Du von daher einfach eine Accessdatenbank mit entsprechenden Tabellen nutzen, die kann man dann auch per Excel öffnen.

Weitere Alternative:

Excel kann mit CSV-Dateien umgehen. Über ADO i. V. m. dem passenden (eigentlich immer vorhandenen) ODBC-Treiber kann man ebenfalls auf CSV-Dateien zugreifen und diese dann in 'nem DBGrid anzeigen.

Ob's für Deine Aufgabenstellung geeignet ist, vermag ich nicht zu sagen, aber Versuch macht Klug.

Danke für die Idee, aber inzwischen hatte ich mich damit abgefunden, dass es eine Zeile mit Header gibt - diese Zeile überschreibe ich, zwar unschön, aber zumindest ist sie weg. Man hat dann im Sheet eine leere Zeile.

Die Wahl auf Excel lag darin, weil er zum einen nur Office 2010 Home hat (da ist kein Access dabei) und Excel-Dateien einfacher zu bearbeiten sind. Es werden aber auch Daten von mehreren Excel Dateien eingelesen und doppelte Einträge gelöscht.

[HolgerX]

Hmm...

Zitat:

Zitat von Mordhorst3k (Beitrag 1492879)

Die Wahl auf Excel lag darin, weil er zum einen nur Office 2010 Home hat (da ist kein Access dabei) und Excel-Dateien einfacher zu bearbeiten sind. Es werden aber auch Daten von mehreren Excel Dateien eingelesen und doppelte Einträge gelöscht.

Dir ist bewusst, das für die Verwendung von Access Datenbank Dateien (zu mindestens für die alten MDB) keine In Installation von Access unter Windows zusätzlich notwendig ist!

Die Jet Engine zusammen mit den ADO Komponenten kann auf MDB Access Datenbanken direkt zugreifen.
Für die neueren Access Formate muss dann doch der aktuelle Treiber (Kostenlos bei MS) installiert werden.

Per ADO kann dann eine Access Datenbank und deren Tabellen angelegt und verwendet werden...

[haentschman]

Moin...:P

Zitat:

weil er zum einen nur Office 2010 Home hat (da ist kein Access dabei)

...da nimmt dann eine freie richtige Datenbank wie Firebird. :zwinker:

[Delphi.Narium]

Zitat:

Zitat von haentschman (Beitrag 1492889)

Moin...:P

Zitat:

weil er zum einen nur Office 2010 Home hat (da ist kein Access dabei)

...da nimmt dann eine freie richtige Datenbank wie Firebird. :zwinker:

Und wie kann man dadrauf mit Excel zugreifen?

Klar, man könnte dann wieder den ODBC-Treiber von anno dazumal für Firebird nehmen und dann über den per Excel auf FireBird zugreifen.

MDB deshalb:
Der C++-Builder kann dadrauf von Haus aus zugreifen.
Excel kann dadrauf von Haus aus zugreifen.

Man braucht dadurch auf beiden Seiten nix, was man nicht eh schon hat.

[haentschman]

...deine Aussage. :wink:

Zitat:

und hier wird Excel eben als Datenbank "missbraucht"

:zwinker:

PS: Den eigentlichen Ablauf, welche Daten wie/wo/Darstellung etc., habe ich noch nicht verstanden. :?

[Delphi.Narium]

Das Problem ist halt:

Excel wird mehr oder weniger datenbankähnlich genutzt.

Nun soll die per Excel erstellte, bearbeitete, ... Datei per Datenbankprogramm verarbeitet, bearbeitet, wieauchimmer werden und das so erhaltene Ergebnis wieder mit Excel bearbeitbar sein.

Grob:

Excel ist hier das Maß aller Dinge und der Rest muss irgendwie damit zurechtkommen ;-)