Guten Tach,
ich speichere ein ADO recordset als Datei ab und lese das aus einer anderen Anwednung wieder ein, ebenfalls als ADO-Recordset.
Zur Frage: Nach dem Einlesen möchte ich das Recordset als Tabelle in der Anwendung abspeichern. Die Anwendung ist ein Access-Frontend.
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 weiß, ich kann ein TableDef erzeugen, in einem DoppelLoop alle Felder in der Tabelle erzeugen und die Daten reinschreiben. Frage: Gibt es einen Standard dafür? Müsste doch!?!
Danke Euch!
Hallo,
warum erstellst Du mit einer Tabellenerstellungsabfrage nicht gleich eine Tabelle ?
Und in der anderen Anwendug diese Tabelle verknüpfen.
ZitatGibt es einen Standard dafür?
Manche haben den Standard Einfachheit und Direktheit, was dann mit Fehlerarmut kooperiert.
Wenn beide Anwendungen mit Tabellen/Abfragen umgehen können, wäre doch die erste Betrachtung einer Prüfung wert, ob sich die zweite Anwendung die Daten direkt per Verknüpfung holen könnte.
Nee und nee,
will ich so nicht aus folgendem Grund:
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.
Das Abspeichern und Re-Initialisieren funktioniert tadellos bis dahin. Daher erscheint mir das erst mal als der optimale Weg. Das einzige was ich suche ist, aus dem Recordset direkt eine Tabelle zu machen.
Klar gibt es etliche Alternativen. Die suche ich aber nicht :o
Zitat von: Milvus am Februar 11, 2019, 21:15:38
Das einzige was ich suche ist, aus dem Recordset direkt eine Tabelle zu machen.
In der Dokumentation findest du alle Möglichkeiten.
Da musst du gar nicht lange suchen. ;D
Hallo!
Die Anwort ist einfach: Du kannst ein Recordset in VBA nicht in direkt in eine Tabelle konvertieren.
Wie ist das Recordset als Datei abgespeichert? Falls das eine xml-Struktur ist: man kann xml auch als Tabelle importieren.
mfg
Josef
ZitatDas einzige was ich suche ist, aus dem Recordset direkt eine Tabelle zu machen.
Mit der Methode Getstring kann man den Inhalt eines Recordsets unmittelbar in eine Texttabelle (CSV) ablegen. In Zusammenhang mit einer Importspezifikation oder einer Schema.ini bzw. in völliger Übereinstimmung mit den Leseregeln für eine Texttabelle aus der Registry wird das eine vollwertige externe datenbanklesbare Tabelle.
Mit einer CSV sollte jede Anwendung klarkommen können.
Zitat von: ebs17 am Februar 12, 2019, 09:54:33
ZitatDas einzige was ich suche ist, aus dem Recordset direkt eine Tabelle zu machen.
Mit der Methode Getstring kann man den Inhalt eines Recordsets unmittelbar in eine Texttabelle (CSV) ablegen. In Zusammenhang mit einer Importspezifikation oder einer Schema.ini bzw. in völliger Übereinstimmung mit den Leseregeln für eine Texttabelle aus der Registry wird das eine vollwertige externe datenbanklesbare Tabelle.
Mit einer CSV sollte jede Anwendung klarkommen können.
Danke, erscheint mir der besten Ansatz.
Zurzeit wird es so gemacht: Das ADO RS wird als .DAT von Anwendung A abgespeichert und die .dat von Anwendung B aufgenommen.
Anwendung B ist auf das Datenmanagement getrimmt, d.h. Exportiert in beliebige Formate und Dinge, wie z.B. Excel.
Das funktioniert auch wunderbar. Anwendung A hatte ein ADO rs und Anwendung B holt sich das ADO rs, womit dann soweit alles machbar ist, was Recordsets betrifft.
Anwednung B kann aber mehr, was mir dem Recordset nicht geht und zurzeit von mir abgeschaltet wurde, nämlich über SQL mit den Daten alles mögliche anzustellen, z.B. filtern. Das geht mit dem rs nicht, dafür braucht es eine Tabelle oder ein gespeichertes View. Daher die Frage, wie man aus dem RS oder der .dat direkt eine Tabelle weg schreibt.
Die Antworten zeigen mir, dass es für das rs bzw. die .dat keine Standardprozedur gibt. D.h. Ansatz wäre dann eher über .csv mit einer Spezifikation.
Zitatz.B. filtern. Das geht mit dem rs nicht
So viel ich weiß, kann man auch ein Recordset filtern (=> Dokumentation lesen), ich gebrauche so etwas aber nicht. Ich bevorzuge Tabellen und SQL ohne die umständlichen Umwege.
Ich filter das auch nicht, noch nie gemacht. Da nehme ich lieber den Standard: SQL.
Mir ist bei der Geschichte noch was aufgefallen.
Es gibt zwei Konstanten zum speichern des ADO-RS:
adPersistADTG
adPersistXML
Ich krieg nur das erste zum Laufen. Unterstützt Access das XML nicht?
Zitat von: Milvus am März 02, 2019, 16:21:57
Es gibt zwei Konstanten zum speichern des ADO-RS:
adPersistADTG
adPersistXML
Ich krieg nur das erste zum Laufen. Unterstützt Access das XML nicht?
Ich kann zwar zur Problemlösung nicht beitragen, aber mit Access hat das hier nichts zu tun. ADO ist in dieser Hinsicht eigenständig und nicht durch Access eingeschränkt o.ä.
Falls Dir der Export als XML gelänge: Kannst Du mit dieser in dieser Form etwas anfangen, oder genügt es, "eine Datei" zu haben?
Naja,
ich suche nach einem Datentauschformat, das mögichst allgemein und easy ist.
XML ist ja ein Standard, das andere Ding kannte ich bis vor kurzem noch nicht.
Worum es mir geht:
1. Aus Source 1 Datei mit Daten ablegen
2. Daten in anderer Andwendung aufgreifen und verwenden
Damit gehts: adPersistADTG
xml aber nicht. Was ist das für n Gespenst?
Weiterhin ohne es ausprobiert zu haben: "Geht nicht" ist eine komplett unzulängliche Problembeschreibung.
Zitatich suche nach einem Datentauschformat, das mögichst allgemein und easy ist
CSV (= Texttabelle) ist an Dir vorbeigegangen?
Ich kann mir kaum etwas Einfacheres und Schlankeres vorstellen, und eine Software, die damit nicht umgehen kann, wird es in einem Umfeld mit geringsten profihaften Ansprüchen nicht geben können.
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.
Wie lässt Du dann dieses folgen, in direkter Form?
ZitatNach dem Einlesen möchte ich das Recordset als Tabelle in der Anwendung abspeichern.
Und jenes?
ZitatZiel 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.
Zitat von: Milvus am März 08, 2019, 16:23:31
Das hat doch was.
Wenn man ein Recordset braucht dann ist das eine Möglichkeit.
In deinem Anwendungsfall ist das doch reiner Unsinn. ;)
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.
Zitat von: Milvus am März 09, 2019, 13:46:26
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.
Zitatmal 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:
ZitatIch 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.
Zitat von: Milvus am März 09, 2019, 13:46:26
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.
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.
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.
ZitatDie 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.
Doch, ist verstanden. ::)