Hallo,

ich habe Daten in einem tDataSet und möchte diese als Folge von Querys in eine Textdatei exportieren, so dass sie anderenorts wieder in eine FireBird-Datenbank importiert werden können. Ich kenne weder Struktur noch Inhalt der Quelldaten muss das ganze also möglichst Flexibel gestalten. Es ist ja recht einfach aus den FieldDefs eine CREATE TABLE Anweisung zu basteln, schwieriger wird es jetzt bei den Daten.
Wo Zahlen und String Werte sich noch leicht in ein Query verwandeln lassen, da wird es mit dem Datums- und Zeit-Werten schon komplizierter.
Zwar kann ich diese in den Formaten 'yyyy-mm-dd', 'hh:nn:ss' und 'yyyy-mm-dd hh:nn:ss' auf meinem System Exportieren und dann auch mit einer FireBird Oberfläche wieder einspielen, nur frage ich mich ob das auch auf anderen Systemen klappen würde, auf denen vielleicht das Windows oder auch der FireBird-Server anders konfiguriert ist? Habt ihr da Erfahrungen? Frisst Firebird diese Datumsformate unter allen Umständen?

Noch spannender wird es da dann bei Blob-Feldern (Subtype 0) kann ich diese irgendwie allgemeingültig in SQL gießen? Eventuell in denen ich sie Hexadezimal in das Query integriere oder so?

Noch mal zur Konkretisierung: Ich habe keinen Zugang zur Zieldatenbank, kann also nicht mit Parametern oder BlobStreams arbeiten, ferner soll meine Funktion für unterschiedlichste Quelltabellen funktionieren. Das Ergebnis muss eine Textdatei mit Querys sein. Es geht mir nur um das Format des Ziel Querys, die eigentliche Delphi-Funktion kriege ich hin, wenn ich weiß wie das Ergebnis aussehen muss.

Ich hoffe ihr könnt mir dabei ein wenig helfen.

critter

Muss der Datenaustausch unbedingt mit SQL-Scripten geschehen?

Für die Definitionen ist ja eine gute Sache (also alles, was DDL ist).
Aber bei den Daten gibt es meiner Meinung nach bessere Wege. Du kannst z.B. die Daten in ein ClientDataSet einlesen. Von dort kannst Du mit TClientDataset.SaveToFile die Daten in eine Datei gießen.

Am Zielrechner kannst Du die Daten dann mit LoadFromFile die Daten wieder in ein ClientDataSet zurückholen. So hast Du die Daten schon mal sehr komfortabel in einem (programmtechnisch) gut verarbeitbaren Format vorliegen. Daraus dann on the fly parametrisierte Insertstatements basteln und die Daten in die Datenbank pumpen.

Hätte für mich den Charme, dass Du Dir über das Dateiformat keine Gedanken machen musst. Außerdem kannst Du bei Blobfeldern die Daten mit parametriesierten Abfragen einfügen (ich wüsste jetzt nicht mal, ob das in einem Einfachen Sql-Statement überhaupt geht).

Moin, Moin,

also für den Datenexport würde ich das XML-Format empfehlen, wir haben da gute Erfahrungen gemacht,
beim Export großer BLOB Felder aus einer Oracle Datenbank.

So ein Import & Export Modul per XML ist ja leicht erstellt.


Beste Grüße
Michael

Hallo,

mit dem Zielsystem habe ich wenig am Hut, dort läuft auch meine Anwendung nicht, die Daten sollen in einem von mir (bzw. dem mir Daten liefernden Gerät) festgelegten Format in eine mir nicht bekannte Datenbank. Ich möchte nur ungern eine zusätzlich Anwendung mitliefern, welche die Daten wieder importiert, auf den FB Server Connectet (wofür der Kunde wieder seine Daten nebst Passwort eingeben muss). Zumal ich mir nicht sicher bin ob es den Kunden recht ist, wenn ich direkt auf deren Datenbanken herum bastle.

Es geht wirklich darum Daten welche per Konfiguration höchst unterschiedlich sein könne zur Verwendung in Fremddatenbanken zur Verfügung zu stellen. Diese Daten stammen nicht aus einer Relationalen Datenbank sondern aus Hardware, welche diese in einem sehr Dynamischen Streaming Format liefert. Ich bereite diese in eine Tabellenstruktur (welche Spalten welchen Typs es gibt hängt vom Input-Stream ab) auf und möchte diese dann in als Querys ausliefern. Der Kunde soll sie möglichst einfach in seine DBs importieren können, ohne das wir explizit hierfür Software schreiben müssen, zumal später sicher auch noch andere DBs als FireBird hinzukommen werden.

Mindestens eine SQL Oberfläche in welcher sie diese Querys ausführen können sollten die Kunden besitzen. Notfalls wäre noch eine Kombination aus SQL (für die Struktur) und csv mit den Daten denkbar, aber auch da bliebe die frage nach dem Datumsformat und der BLOB Struktur, nur würden eben mehr Kunden dazu verurteilt sich Konvertierungstools für eben diese Daten zu schreiben. Wenn es also einen Standard der jeweiligen Datenbank (in diesem Fall FireBird) gibt möchte ich möglichst diesen nutzen.

Also noch einmal: Ich muss eigentlich alles auf dem Quellsystem machen, auf dem Zielsystem habe ich nichts zu suchen.

Dennoch danke für die Vorschläge,

critter

Wenn Du die Zieldatenbank nicht kennst, wie stellst Du dann z.B. sicher, dass die Tabellen, in die Du importierst, nicht schon für andere Zwecke existieren?
Ich denke, wenn man Daten in Fremdsysteme übergeben muss, kommt man um eine gut definierte Austauschschnittstelle nicht drum rum. Diese Schnittstelle musst Du befüllen und der Empfänger muss sie auslesen. Nur so kann der Empfänger kontrollieren, ob die Daten auch in seine Datenstrukturen passen, nicht irgendwelche Integritätsregeln verletzen, etc.
Meine Meinung: schreib die Daten in XML-Dateien und dokumentiere sie. Wie der Empfänger die Daten ausliest ist dann sein Problem.
Ich als Datenempfänger würde nicht wollen, dass da irgendwelche SQL-Scripte auf meine Datenbank abgefeuert werden, die jemand "fremdes" erstellt hat.

Jens

Hallo,

Nersgatt hat folgendes geschrieben :

Wenn Du die Zieldatenbank nicht kennst, wie stellst Du dann z.B. sicher, dass die Tabellen, in die Du importierst, nicht schon für andere Zwecke existieren?

durch ein aussagekräftiges Sufix.

Nersgatt hat folgendes geschrieben :

Ich denke, wenn man Daten in Fremdsysteme übergeben muss, kommt man um eine gut definierte Austauschschnittstelle nicht drum rum.

Wir haben bereits die Möglichkeit die Daten in diversen anderen Formaten zu exportieren. Einige Kunden haben allerdings den Wunsch, die Daten möglichst direkt in Ihre Datenbank zu importieren damit sie für die individuelle Auswertung eben nicht mehr Aufwand treiben müssen als ein paar Views auf diese zusätzlichen Tabellen zu definieren.

Nersgatt hat folgendes geschrieben :

Diese Schnittstelle musst Du befüllen und der Empfänger muss sie auslesen. Nur so kann der Empfänger kontrollieren, ob die Daten auch in seine Datenstrukturen passen, nicht irgendwelche Integritätsregeln verletzen, etc. Meine Meinung: schreib die Daten in XML-Dateien und dokumentiere sie. Wie der Empfänger die Daten ausliest ist dann sein Problem.

Wie gesagt, es soll hier in dem Thread nicht um das Exportprinzip selbst gehen, das ist mit einigen Kunden und Firmenintern ausreichend durchdiskutiert, es geht her nur um technische Details bei der Umsetzung, also den zu Erzneugenen Querys.

Hierzu noch ein kleines Update, für den Fall, dass irgendwann einmal jemand vor einem ähnlichen Problem steht:
Blob-Felder im Firebird lassen sich mit der Notation x'03F1EDACB9' füllen, also einem x gefolgt von einem gequoteten Hex-String. Leider darf der Hex-String nicht länger als 32kByte sein und das Gesamtquerry nicht länger als 64kByte sein, was zwar ärgerlich ist, bei den zu erwartenden Daten aber nicht relevant.

In einem Query würde das beispielsweise so aussehen:


Diese Notation kann man übrigens auch genau so für MySQL nutzen, für MS-SQL müsste es so aussehen: 0x03F1EDACB9, also keine Quotes sowie eine null vor dem 'x' und Oracle akzeptiert das direkt als gequoteten Hex-String '03F1EDACB9'.

Bliebe also nur noch die Frage, ob das von mir verwendete Datumsformat immer funktioniert oder auf anders konfigurierten Systemen scheitern könnte. Irgendwie gelingt es mir nicht Suchanfragen zu formulieren, die mir diese Frage eindeutig beantworten .

critter

Critter hat folgendes geschrieben :

Bliebe also nur noch die Frage, ob das von mir verwendete Datumsformat immer funktioniert oder auf anders konfigurierten Systemen scheitern könnte. Irgendwie gelingt es mir nicht Suchanfragen zu formulieren, die mir diese Frage eindeutig beantworten .

Gerade zufällig drauf gestoßen und dabei an Dich gedacht:
firebirdfaq.org/faq137/

demnäch gingen diese Formate:
DD.MM.YYYY
MM/DD/YYYY
YYYY-MM-DD

Cool, danke für den Link.

demnach sollte meine Lösung ja funktionieren. Damit ist das Thema hier ja erledigt.

Danke noch einmal
critter