Ich weis, es ist etwas umständlich, aber es soll so sein.
Ich möchte über ODBC auf eine Excel Tabelle zugreifen und habe mir auch die netsprechende Datenquelle erstellt. Funzt auch alles soweit bis auf das Open() vom Recordset:

keys.Open(CRecordset::snapshot,"Select * from NameTabele Where Name = 'Heinz'");

Das schlägt fehl, weil er "NameTable" nicht kennt, obwohl die Tabelle im Excel genau so heißt. Ich hba dann mal in den Standard SQL String geschaut im erstelletn CRecordset, da stand drin

return _T("[Tabelle1$]");

Wenn ich jetzt in mein SQL Statement reinschreibe:

keys.Open(CRecordset::snapshot,"Select * from Tabelle1$ Where Name = 'Heinz'");

Dann bekomme ich den Fehler: "Fehler in der FROM Klausel!"

Kann mir jemand helfen??

Gruß und Dank Ranger

keys.Open(CRecordset::snapshot,"Select * from [Tabelle1$] Where Name = 'Heinz'");

und hier noch ein paar Hinweise:

Excel:

1.Generelles:
-Am einfachsten connected man mit Hilfe des „Excel-Dateien“-Treibers, eine
eigene DSN zu erstellen macht wenig Sinn, da es sich dabei sowieso um einen
ganz normalen Excel-Treiber handelt. Außerdem erspart man sich dadurch die
lästigen „Extended Properties“, die so nicht gesetzt werden müssen. „READONLY“
muss so auch nicht explizit auf FALSE gesetzt werden. Der eigentliche
ConnectionString bleibt kurz und übersichtlich und leistet dabei dasselbe wie
eine eigene DSN.

-Tabellennamen werden grundsätzlich in eckige Klammern gepackt. Dabei muss der
Tabellenname immer mit einem „“-Zeichen abgeschlossen werden. Das gilt für alle SQL-Befehle, nicht nur für „Select“ ! Beispiel : \[MyTable]. Die MSDN
behauptet, man könne auch ohne eckige Klammern auf „Ranges“ zugreifen. Das mag
für VB gelten, bei Delphi hatte ich bis jetzt noch keinen Erfolg. Bleibe aber
weiter dran...

-Excel-Tabellen können grundsätzlich nur einmal geöffnet werden. Das sollte
beim Debuggen berücksichtigt werden. Eine Connection, die auf TRUE steht, kann
stören. Meines wissens nach ist es auch nicht möglich, besagte Tabelle ein
zweites mal im Exclusiv-Modus zu öffnen.

2. Einen Connect ausführen
-Ein typischer ConnectionString sieht in etwa so aus:

-ConnectionString := ’Provider=MSDASQL;Data Source=Excel-Dateien;Initial
Catalog=C:\myTable.XLS;’

-Mehr ist nicht nötig, man glaubt es kaum...

3. CREATE DATABASE
-Ein CREATE DATABASE ist nicht so ohne weiteres anwendbar. Man muss einen
kleinen Trick anwenden. Man connected auf eine Datei, die bis jetzt noch nicht
existiert. Dann führt man einen CREATE TABLE aus. Der Treiber erzeugt dann
automatisch die .XLS-Datei. Die DataBase (sprich das XLS-File) heißt dann so,
wie zuvor angegeben.

4. CREATE TABLE
-Hier gilt es zu berücksichtigen, dass außer dem Tabellennamen auch die
Feldnamen in eckigen Klammern stehen müssen! Excel kennt eine Vielzahl von
Formaten, darunter VARCHAR, DOUBLE, CURRENCY oder DATETIME. Einen Typ "int"
gibt es nicht! Zahlen werden generell als "Double" angegeben. Ein typischer
CREATE TABLE könnte so aussehen:

-CREATE TABLE [myTable$] ([Name] varchar(50), [Vorname] varchar(50), [PLZ]
Double, [GeburtsDatum] DateTime)

-Die Feldnamen erscheinen im Worksheet dann in der ersten Zeile. Die msdn
behauptet, man könne mit "FirstRowHasNames" die erste Zeile zu einem weiteren
Datensatz machen, ich hatte bisher keinen Erfolg damit.

5. Zugriff & Manipulation
-Zugegriffen und manipuliert wird auf ganz normale Art und Weise. Bei
einem "Insert" können jetzt auch die eckigen Klammern weggelassen werden. Beispiel:

-INSERT INTO (Name, Vorname, PLZ, GeburtsDatum) values (’Müller’, ’Martin’, 74523, 22.02.02)

-ansonsten funktioniert alles im SQL-typischen Stil.

6. Abschließendes
-als sehr kooperativ erweist sich Excel mit Datums- und Currency-Werten. Wenn
man die Felder bereits richtig definiert, kann man auch mit Sicherheit davon
ausgehen, dass alle Zellen richtig formatiert und angezeigt werden. Hier
leistet der Treiber ausgezeichnete Arbeit.

-Leider ist es IMHO nicht möglich, den Feldtyp VarChar(x) richtig zu
beeinflussen. Excel macht sich nichts aus der Größe x, es legt sich
anscheinend soviel Speicherplatz an chars zurecht, wie es (Excel) meint, zu
benötigen. Wenn man die Daten dann im Excel anschaut, ist das kein Problem;
wird allerdings versucht, die Daten mit einem Grid anzuzeigen, gibt das Probleme, weil die Felder überdurchschnittlich groß geraten sind.

-stets beachten sollte man auch, dass Excel nicht in der Lage ist, mehr als
65535 Datensätze zu speichern. Das ist aber ein Problem der Excel-Philosophie.

7. Wichtiges
-Ein SELECT * FROM kann nicht ausgeführt werden. Woher sollte Excel auch
wissen, wann das Ende der Feldnamen erreicht ist? Und wenn, was würde es dann mit leeren Einträgen machen, die im Excel ja durchaus zulässig sind?

for allem der letzte dürfte hilfreich sein

Danke, Ranger

Ach ja und evtl auch wichtig: total sinnloser weise unterstützt Excel kein DELETE FROM (steht auch so in der MSDN)