![]() |
DB-übergreifende Abfrage / Kopie einer Tabelle
Ich möchte über ein TADOQuery-Objekt eine INSERT-Abfrage absetzen, die das Ergebnis einer Abfrage in Datenbank A in eine Tabelle in Datenbank B schreibt.
Also in etwa so: INSERT INTO Zieltabelle (Field1, Field2,...) SELECT FieldA, FieldB... FROM Quelltabelle1, Quelltabelle2; Wie kann ich nun mit einem TADOQuery-Objekt auf zwei (oder mehr) DB zugreifen. Oder muss ich das anders angehen ? Eine Lösung könnte in meinem Fall auch so aussehen, dass ich zunächst die benötigten Quelltabellen aus DB A in DB B kopiere, um gleichzeitig den Datenbestand zu sichern. Wie lässt sich so ein Kopiervorgang realisieren ? Tobias |
Zur Ergänzung:
Bei den Datenbanken A und B handelt es sich um Access-Datenbanken. Der Zugriff erfolgt - wie schon erwähnt - über ADO). Bei BDE gibt es TBatchMove, um Daten zwischen zwei Table-Objekten auszutauschen. Hat ADO auch etwas Ähnliches zu bieten ? Damit könnte ich dann zunächst eine Kopie der Quelltabelle (Datenbank A) in der Datenbank B anlegen. Nicht schön, aber selten.... |
Willst du nur eine exakte Kopie haben?
|
Hallo,
ist bei mir zwar schon lange her, aber die Lösung sind heterogene Joins (Verknüpfung versch. Tabellen):
Code:
1. Ziel-DB
1. INSERT INTO "customer.db"
2. (custno, company) 3. SELECT a.custno, b.company 4. FROM oldcustomer a, oldcustomer1 b 5. WHERE a.custno = b.custno 2. Felder die eingefügt werden sollen 3. 'Schnittstelle' zu 2. von den Quell-DBs (a... Tab1, b.. Tab2) 4. Quell-DBs 5. Bedingung(en) Das sollte mit einem TADOQuery auch funktionieren. :mrgreen: Tip: Probiere deine Statements im Datenbankexplorer aus, bevor Du sie codierst. Tip2: Versuche zuerst nur die Zeilen 3-5 an Deine Bedürfnisse anzupassen, d.h. führe nur diese Statements im Datenbankexplorer aus um zu sehen ob alles funktioniert. Später kannst Du noch immer das INSERT INTO einbauen... p.s Weiter Hilfe zu SQL findest du in Deinem Delphi (bei mir D5)-Verzeichnis unter Delphi5\Help\del5xtra.hlp |
@X-Dragon:
Ja, eine exakte Kopie der Tabelle reicht. Hauptsache, ich habe die Quelltabellen aus Datenbank A in die Datenbank B übertragen. Alle weiteren DB-Operationen kann ich dann über eine ADOConnection mit der Zieldatenbank B steuern, da dort dann alle für die Abfrage nötigen Tabellen vorliegen. @APP: Das von Dir vorgeschlagene SELECT-Statement kann ich AFAIK nur an eine Datenbank absetzen, die Quell- und die Zieltabelle liegen aber in zwei unterschiedlichen Access-Datenbanken, deren Tabellen sich leider nicht so einfach über die db-Files ansprechen lassen wie bei Paradox-DBs. Oder ? |
Hi !
Ich habe so ähnliches Problem! :cry: Und sofern ich weiß muss du Zwei Querys benutzen da jedes von denen nur eine direkte Verbindung hat und wenn du die Verbindung änderst geht ResulSet verloren (die Daten in Query)! Drum musst Du erst die Daten von Query1 speichern und sie der Zweiter Query2 übergeben damit es ein INSERT oder UPADE auf die Datenbank machen kann! Du schriebst ja zwei Datenbanken NICHT Tabellen oder! Bei Nur Tabellen ist es anders. :!: Gruß ……-=<Nexio>=-… |
Zitat:
Zitat:
[edit=Daniel B]BB-Code wieder eingeschaltet, damit die Tags funktionieren. MfG Daniel B.[/edit] |
Hallo Nostromo73 8)
Es gibt’s verschiedene Wege Dein Problem zu lösen... Allerdings von Benutzung dynamischer Strukturen wie z.B. Dyn. ARRAY oder TListen würde ich Dir an dieser Stelle abraten Ein davon wäre z.B. die Benutzung von Fremd-Komponenten wie z.B. TMemoryTable von Rx-Komponenten. Diese habe ich mal erfolgreich mit Delphi 5 für ähnliches Problem benutzt. Hier kannst Du Deine Daten unabhängig von aktuellen Session zwischenspeichern. Eine andere Methode (die ich auch schon erfolgreich eingesetzt habe... allerdings nicht für dieses Zweck) wäre aus der Kompleten Quelle-Tabelle ein „INSERT INTO“ – Script zu erzeugen und dann in der anderen Datenbank auszuführen. Ich habe mal ein DB-Tools geschrieben die unter anderem aus jeder beliebiger (unbekannter) Tabelle dynamisch so ein SQL-Script erzeugen kann...Allerdings für Dich wäre das ein zu großer Aufwand um so was zu bewältigen. Also sehe Dich nach entsprechenden Fremd-Komponenten um :roll: ...und Du wirst sehen wie leicht das Ganze ist... :idea: Gruß Paul Jr. |
@nostromo73
so ganz kann ich das nicht "Unterschreiben": :coder: Zitat:
Gestern benutzte ich für mein Beispiel den Datenbankexplorer und den Alias "DBDEMOS", der wenn Du nachschaust, verschiedene Tabellen vom Typ *.dbf und *.db beinhaltet. Hier ein Auszug aus der LokalSQL-Hilfe: Zitat:
Mein Beispiel funktioniert also für "verschiedene Datenbanken", ob allerdings TADOQuery dies auch unterstützt weiß ich nicht, da ich damit nicht arbeite, einfach ausprobieren :mrgreen: |
Hallo Nostromo 8)
Also... ich habe mich natürlich heute von meinen Vorgänger irgendwie beeinflussen lassen... :shock: (von wegen NICHT MÖGLICH??? ) und da musste ich schmunzeln... :roteyes: wie blöd ich manchmal bin... Ich habe doch vorher davon gesprochen... dass ich DB-Tools geschrieben habe... und da musste ich plötzlich (heute Abend) feststellen, dass diese Tools verwende ich AUCH um verschiedene Datenbanken GLEICHZEITIG anzuzapfen... um die Daten zu konvertieren (von Datenbank zu Datenbank)... und zwar für alle mögliche wie z.B. ORACLE/ SQL-Server/ INTERBASE / MySQL/ACCESS und was man noch so will...Allerdings benutze ich dazu als Zwischenstufe BDE...und zwei TDataBase Komponenten... Es ist einfach und sauber... Du stellst via TDataBase getrennte Verbindungen zu jeweiliger Datenbank... und per entsprechende TDatasets (also TQuery oder TTable oder andere...) die an den besagten getrennten TDataBase „hängen“ öffnest Du zuerst die entsprechenden SQL-Tabellen (am besten Query als Quelle und TTable als Ziel)... dann läuftst Du die Quelle seqeuntiel durch und kopierst Du Datensatz für Datensatz in die ZIEL-Datenbank... Es ist wirklich sehr einfach... und SORRY für meine vorherige Klugsch..ßereien :warn: ..., aber das kommt davon, dass ich immer sehr wenig Zeit habe... Gruß Paul Jr. P.S. Übrigens... dies funktioniert für ALLE DataSet Komopnenten also auch für ADO und Zeus... etc... |
Zitat:
deine Lösung ist nur dann nicht so einfach anwendbar, wenn sich die Struktur der zu kopierenden Tabelle von Zeit zu Zeit ändert. Das hätte ich schon dazu schreiben können. Sorry ! Dieser Fall kann in meiner Anwendung auftreten, weil die Quelltabelle aus Datenbank A dynamisch ist, es können also Attribute (Spalten) hinzugefügt werden (es handelt sich um eine andere Anwendung, die mit diesen dynamischen Tabellen arbeitet, kann ich leider nicht ändern !). Die Interpration der (selten) hinzugefügten Attribute erfolgt dann in meiner Anwendung über eine separate Zuordnungstabelle. Das funzt auch schon problemlos. Der gesamte Ablauf ist folgendermaßen gedacht:
Kurzum: Ich muss eine dynamisch erweiterbare Tabelle (Struktur+Inhalte) mit ADO von Datenbank A nach Datenbank B kopieren. Das muss doch auch einfacher gehen, als umständlich zwei Querys (dynamische Tabellenstruktur berücksichtigen !) zusammenzubasteln und Datensatz für Datensatz einzeln rüberschaufeln. Ich hatte auch schon überlegt, ob ich von Delphi aus eine Tabelle in Access importieren kann, quasi, als ob ich direkt die mdb öffne und manuell 'Tabelle importieren' wähle. Das wäre auch eine elegante Lösung... Auf jeden Fall habe ich durch Eure bisherigen Antworten schon viel dazu gelernt. Und darum geht es letztlich...Danke ! |
Hallo Nostromo73 8) ,
(...) deine Lösung ist nur dann nicht so einfach anwendbar, wenn sich die Struktur der zu kopierenden Tabelle von Zeit zu Zeit ändert. Das hätte ich schon dazu schreiben können. Sorry ! (...) Natürlich es gibt eine elegantere Lösung... :D ich mache es z.B. so... wenn ich mit einer Unbekannter- SQL- Struktur konfrontiert werde: 1.) Eine Datenbank wird ausgewählt 2.) Alle vorhandene Tabellen werden ausgelesen 3.) Eine Tabelle wird ausgewählt 4.) Aufbau der ausgewählten Tabelle wird analisiert und eine universelle (unabhängige) SQL- Tabellen Definition (also CREATE TABLE blabla, ... NOT NULL , Schlüssel etc...) wird generiert. 5.) Ziel Datenbank wird ausgwält (z.B. ORACLE oder Interbase etc...) 6.) In dem Ziel-Datenbak wird die neue (KLON) Tabelle erzeugt. 7.) Daten werden automatisch von Datenbak A in die Datenbank B kopiert So... Wünsche Dir viel Erfolg... :coder: Gruß Paul Jr. |
Zitat:
Noch eine kleine Frage, dann habe ich endlich das nötige Know-How... Gibt es eine Funktionalität in Delphi, die mir zu einer Tabelle direkt die SQL-Tabellendefintion mitsamt Primärschlüssel etc. und ausspuckt oder muss ich da etwa durch alle Spalten durchgehen und die Attributnamen einzeln an das "Create Table..." anhängen ? |
also dass ist schon etwas mühsam...dafür das Ergebnis lässt sich später sehen!
Man muss schon richtig den Aufbau einer Tabelle (also z.B. die Spalten durchgehen usw...) analisieren bzw. auslesen... Dafür gibt’s z.B. TDataSet eigenschaften wie FieldDefs die Dir schon sehr viel verrät... Ich habe aber schon auch die SQL- SYSTEM- Tabellen analisiert um an gewisse Informationen (wie z.B. Trigger) zu kommen... aber das ist zu unflexibel.. und schwierig (zeitaufwändig)... Also noch einmal viel Erfolg Gruß Paul Jr. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:11 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz