Access Datenbank mit ADODataSet

[Der schöne Günther]

Ich kenne mich mit Datenbanken nicht aus, habe aber vor ein paar Wochen auch einmal kurz schnell etwas für Access mit den ADO-Komponenten zusammengezimmert.

Ich kann nur sagen, dass ich drei Komponenten hatte, in dieser Reihenfolge aufeinander aufbauend:


TDataSource->(ADOTable|AdoQuery|…?)->ADOConnection:<Jet, OLE DB, ODBC>

TDataSet ist eine implementierende Unterklasse von TDataSource, oder? Somit müsste das Teil doch entweder an einem ADOTable- oder ADOQuery-Objekt dranhängen?

[MechMac666]

Also die Datenbankverbindung an sich klappt wunderbar. Auch die SQL-Abfragen funktionieren.

Das einzigste "Problem" was ich habe, ist das mir nicht klar ist, woher "das System" weiß, in welcher Tabelle ich den neuen Datensatz erstellt haben möchte.

DataSource -> ADODataSet ->DBGrid etc.

[Rainer Wolff]

Ich habe nie mit dem ADODataset gearbeitet, sondern nur mit ADOTable/ADOQuery, daher kenne ich die Komponente auch nicht. Aber ich zietiere mal aus der Delphi-Hilfe:

Die Datenmenge wird mit Hilfe der Eigenschaft CommandText des TADODataSet-Objekts abgerufen. Weisen Sie dieser Eigenschaft den betreffenden Tabellennamen oder eine SQL-Anweisung (nur SELECT) zu. Mit der Datenmengenkomponente können nur DML-SQL-Anweisungen (Data Manipulation Language) ausgeführt werden, die eine Ergebnismenge zurückliefern. Für SQL-Anweisungen wie DELETE, INSERT und UPDATE sind Komponenten wie TADOCommand oder TADOQuery besser geeignet.

Demnach also für Insert nicht zu empfehlen

Gruß Rainer

[blondervolker]

ADOConnection
DataSource
ADOTable

Leg noch ein Datenmodul an und klatsche da alles drauf.
Dann lege eine oder mehrere Forms an und schreibe in Uses Datamodul oder
wie das Ding auch immer heissen soll.

Dann klatsche eine Tabelle auf eine Form und schau dann im Objektinspektor
was für eine Tabelle oder Table usw. zugewiesen werden soll.

Siehe Abb.1

[Bernhard Geyer]

Wenn was in Access trotz keiner Fehler nicht sichtbar ist liegt das am bescheuerten Caching-Verhalten von Access.

Im Entwickler-Forum gabs mal Beispielcode wie man die Jet-Engine zwingen kann ohne jedesmal die Verbindung zu beenden den Cache zu leeren..
Leider finde ich den Beitrag nicht mehr. War von Andreas Kosch.

[MechMac666]

Ähm? Nicht sichtbar?

Also wenn ich einen neuen Datensatz erzeuge ist der schon sichtbar, er ist nur nicht in der Tabelle wo ich ihn gerne hätte.
Ich verbinde das ADODataset mit einer Datenbank. Im Connectionstring steht nix von einer Tabelle o.ä. Da lege ich nur fest welche Datenbank.
Wenn ich nun ne Abfrage mache, ist es mittels SQL ja kein Problem diese Abfrage über mehrere Tabellen laufen zu lassen.

Und nun gehe ich her und erstelle einen neuen Datensatz.

ADODataSet1.Insert; <--Toll, "insert"..Und wo? Er weiß doch gar nicht in welcher Tabelle er das einfügen soll.

Im Notfall kann man ja auch mittels SQL nen Datensatz erzeugen. Das werde ich dann wohl auch machen müssen, wenn es mit den Delphi Hausmitteln vom Zufall abhängig ist, wo meine Daten landen.
Aber erstmal abwarten, vielleicht meldet sich ja noch jemand der das Problem schon mal hatte

[Volker Z.]

Hallo,

Zitat:

Im Notfall kann man ja auch mittels SQL nen Datensatz erzeugen. Das werde ich dann wohl auch machen müssen, wenn es mit den Delphi Hausmitteln vom Zufall abhängig ist, wo meine Daten landen.

Es hängt nicht vom Zufall ab. Ließ Dir mal die OH zu dem Thema durch.
TADODataSet verwenden
TADODataSet

Dann wirst Du über die Eigenschaften CommandText und CommandType stolpern. Mit:

Delphi-Quellcode:

ADODataSet1.CommandText := 'Tablename'; // z. B. 'BILDER'
ADODataSet1.CommandType := cmdTable; // bzw. cmdTableDirect
ADODataSet1.Insert;
ADODataSet1.FieldByName ('Fieldname').AsString := 'Fieldvalue';
[...]
ADODataSet1.Post

sollte einen Datensatz in die Tabelle schreiben. (Nicht getestet)

Aber wie hier und in der OH schon erwähnt ist für ein INSERT TADOCommand besser geeignet.

Gruß