ADO recordset in und aus Datei

[Milvus]

Ja, das ist richtig. Das ist nicht an mir vorbei gegangen. Nutze ich auch.

AAAAber: ADO bietet halt für diese beide Methoden ein direktes abspeichern und einlesen von Recordsets an. Das hat doch was.

[ebs17]

Wie lässt Du dann dieses folgen, in direkter Form?

Nach dem Einlesen möchte ich das Recordset als Tabelle in der Anwendung abspeichern.

Und jenes?

Ziel ist: Es soll SQL bei den importieren Daten möglich sein. Das ist dann wohl am einfachsten, wenn die Daten in einer Tabelle vorliegen.

Ich persönlich tue mich da einfacher, wenn ich direkt auf Tabellen orientiere. Ein Recordset  ist einfach und schnell aus einer Tabelle zu erzeugen, der umgedrehte Weg ist mir verborgen geblieben, außer man dreht Schleife um Schleife ... mir wird so schnell schwindelig.

[markusxy]

Das hat doch was.

Wenn man ein Recordset braucht dann ist das eine Möglichkeit.
In deinem Anwendungsfall ist das doch reiner Unsinn. 

[Milvus]

Ihr habt vermutlich recht.

Ich werde das mal auf CSV umstellen und die Perfomrance beobachten. Da kommt für mich aber nur noch ADO in Frage, mit driektem SQL Zugriff auf die Files. DAO häng ich da definitiv an den Haken. DAO macht doch - mal nüchtern betrachtet - nur Sinn bei verknüpften Tabellen, eine Access Spezialität.

Ich setze das auf gelöst, auch wenn die urprüngliche Fragestellung zum XML nicht geklärt wurde.

[markusxy]

Ich werde das mal auf CSV umstellen und die Perfomrance beobachten.

Um Daten zwischen zwei gleichen DatenbankSystem auszutauschen, gibt es immer einen hochperformanten Weg.
Bei Access verwendet man - außer man befindet sich in einem performanten Netzwerk - eine Access Datei.
Da muss nichts konvertiert werden - das kostet doch die meiste Zeit.

[ebs17]

mal nüchtern betrachtet

Interessant, wenn so etwas explizit hervorgehoben werden muss ...
Die daran gehängte Aussage ist höchst diskutabel.

Ob ich eine externe Tabelle in die Access-DB verknüpfe oder per DAO verbinde oder per ADODB verbinde, ist meist eher eine Stil- denn eine Performancefrage, wenn man noch nicht über verwendete DBMS und verwendbare Treiber dazu nachdenkt. Die Performance hängt dann eher davon ab, was genau mit der Tabelle angefangen wird. Es gibt nicht das SQL, sondern durchaus gut formulierte und schlecht formulierte SQL-Anweisungen, also auch individuell bedingte mögliche Varianzen.

Und eigentlich und in Wiederholung:

Ich habe n Frontendanwendungen aus denen ich Daten ablegen will, die von einem weiteren Frontend verarbeitet werden. Dieses Frontend enthält ausschließlich Klassen und keine direkte Verbindung zu den anderen Anwendungen und die will ich auch nicht haben, auch nicht temporär.

Zwischen Frontends wird man auch kaum verknüpfen, Tabellen liegen in Backends. Also würde man direkt auf Tabellen des einen Backends zugreifen und damit die Tabellen des anderen Backends bedienen, vorzugsweise unmittelbar per SQL und unter Verzicht der geschätzten Klassen. Das kann genau ein Frontend als Steuerung dazu erledigen.
Idealerweise müsste man gar nicht zwischen verschiedenen Backends pendeln.

[PhilS]

Ich setze das auf gelöst, auch wenn die urprüngliche Fragestellung zum XML nicht geklärt wurde.

Könnte das damit zusammenhängen, dass dir bisher weder der verwendet Code noch eine konkrete Problembeschreibung zu entlocken war?

In den meisten Fällen stimme ich den hier geäußerten Einwänden zugunsten anderer Formate zu. Anders als die genannten Alternativen funktioniert ADO-XML auch ohne eine Access-Installation und kann hierarchische Daten (1-N) in einer Datei speichern. - Es mag Szenarien geben, in denen das ein Vorteil ist.

[Milvus]

Ich schreib noch mal was zum Anwendungsszenario:

Die Logiken zum Berechnen und Abfragen von Daten sind in den jeweiligen Frontend-Anwendungen integriert, in Form von verschachtelten Funktionen über Module verteilt. Es soll aber nur eine Anwendung zum Abfragen der Geschäftsdaten geben.

Damit ich diese Welt nicht nachbauen muss, muss die Abfrage also innerhalb der jeweiligen Anwendung ausgeführt werden. Das funktioniert ja schön, z.T. Dank Eurer Hilfe (Danke an alle). Das habe ich jetzt erst mal mit einer Tauschdatei gemacht, mit dem gespeicherten ADO Recordset.

Hier fehlt mir allerdings die Möglichkeit die Daten noch durch SQL weiter aufzubereiten, z.B. Filter zu setzen. Ich denke, wenn ich auf CSV umstelle, kann ich mit ADO direkt per SQL auf diese Datei zugreifen, damit wäre das Thema dann gelöst.

[MzKlMu]

Hallo,
üblicherweise wird die CSV nicht importiert, sondern nur verknüpft. Dann schiebt man mit einer Anfügeabfrage die Daten aus der CSV in eine vorgefertigte Access Tabelle. Dann kann man die den üblichen Access Funktionen auf die Daten zugreifen. Die CSV ist dann bedeutungslos und nicht mehr notwendig.

[ebs17]

Die Logiken zum Berechnen und Abfragen von Daten

Für eigene spezielle Abfragen oder einen simplen Datenaustausch benötigt man doch gar keine anderen "Logiken".
Oder sind Deine Datenstrukturen derart verschlüsselt und zerlegt, so dass man erst durch spezielle Verarbeitung einen Zugang dazu gewinnt? Das kann ja auch Sinn machen, ist aber eine andere Ebene als Einfachheit, Direktheit und Performance, und wer so etwas bewusst tut, darf es eingangs auch als solches explizit benennen.

Falls Du es noch nicht verstanden hast: Auf ein Recordset kann man kein SQL aufsetzen.  Da ist der Zug bereits abgefahren.

[Milvus]

Doch, ist verstanden.