Entwickler-Ecke :: Thema anzeigen - Datenbankinhalt in ein SQL-Skript (Struktur & Daten)

bis11 - Di 11.02.03 16:44
Titel: Datenbankinhalt in ein SQL-Skript (Struktur & Daten)

Hallo Leute,

gibt es eine Möglichkeit oder eine Komponente womit ich aus einem Datenbankinhalt ein SQL-Skript erstellen kann ? Das SQL-Skript soll dann unabhängig zu den Datenbanken laufen. Ich möchte dieses SQL-Skript sozusagen als Sicherung meiner Datenbank haben. Ich habe allerdings keinen Lösungsansatz, wie ich das realisieren soll. Wer kann mir helfen ?

@Marc
Habe den Titel geändert.

Udontknow - Di 11.02.03 17:22

Hallo!

Der IB-Expert beherrscht das. Sämtliche Daten (auf Wunsch auch Metadaten) von Interbase-DBs können so festgehalten werden. Er kostet zwar eine Kleinigkeit, ist aber sein Geld wert. Für Schüler gibt es glaube ich sogar eine kostenlose Lizenz.

Cu, :)
Udontknow

UGrohne - Di 11.02.03 17:24

Erstell doch einfach regelmäßig ein Backup der Datenbank, das ist das einfachste. Einfach aus den IBAdmin-Komponenten nehmen.

Würd mir mal so einfallen....

Ansonsten gibts glaub ich die Möglichkeit erstens die MetaData aus Interbase auszulesen, zweitens müsstest Du dann alle Datensätze durchgehen, was bei Netzwerk-DBs ein Transfer-Problem geben könnte. Deswegen empfehle ich Dir ein Backup auf ServerSeite, da kannste auch von einem Client aus steuern lassen.

Gruß

bis11 - Di 11.02.03 17:53

Das stellt mich noch nicht zufrieden. Die SQL-Skript Sprache ist doch für alle Datenbank oder nicht ? Bis natürlich auf ein paar besonderheiten. Aber um eine Datenbank zu erstellen mit Tabellen kann ich doch ein und das selbe SQL-Skript nehmen, egal welche Datenbank ich habe oder ?

Lemmy - Di 11.02.03 18:04

Hi,

bis11 hat folgendes geschrieben:

Bis natürlich auf ein paar besonderheiten. Aber um eine Datenbank zu erstellen mit Tabellen kann ich doch ein und das selbe SQL-Skript nehmen, egal welche Datenbank ich habe oder ?

Und genau diese "Besonderheiten" werden Dein Problem werden. Stored Procedures gibts halt nicht in allen SQL-DB's, ebensowenig wie Transactions, verschiedene Datentypen usw. Bis heute gibts so gut wie keine Datenbank die SQL92 VOLLSTÄNDIG umsetzt. Jede hat proprietäre Erweiterungen, die es so nicht in anderen DB's gibt. Vergiss also diesen Ansatz und schau Die lieber die Service-Komponenten an!

Grüße
Lemmy

bis11 - Di 11.02.03 18:13

Ich arbeite schon lange mit Datenbanken, allerdings nur in kleineren Netzen, maximal 10 User. Aber wozu brauche Stored Procedures zum Beispiel ? Ich habe das bis jetzt noch nie gebraucht.

Lemmy - Di 11.02.03 20:24

Hi,

in einer Stored Procedure kannst Du eine bestimmte SQL-Abfrage direkt auf dem Datenbankserver "speichern" und dann direkt dort ausführen, was etwas mehr an Performance bringt. Neben "Standard"-SQL gibt es aber auch Spracherweiterungen wie If-Abfragen, Schleifen usw. und damit kann man viele Aufgaben die die Clients erledigen auf den Server übertragen. Das spart zum einen Zeit und Geld (Netzverkehr sinkt) und zum anderen kannst Du diese StoredProcedures wesentlich einfacher ändern als viele Client-Installationen.

Aber selbst bei kleinen DB-Systemen wird Dein Wunsch nicht in Erfüllung gehen, denn ein Access-Skritp wirst Du niemals in der Datenbankoberfläche ausführen können um ne Paradox-Tabelle zu erstellen....

Grüße
Lemmy

bis11 - Di 11.02.03 20:30

Hi,

das heißt also, ich kann mir nur SQL-Skripts erstellen zu der jeweiligen Datenbank. Ich kann also nicht einfachste Create und Insert-Befehle auf mehrere Datenbank anwenden.

Hab ich das soweit richtig verstanden ? :?!?:

hansa - Di 11.02.03 20:42

bis11 hat folgendes geschrieben:

Lemmy hat doch in soweit alles geschrieben, allerdings ist hier vielleicht ein Mißverständis aufgetreten : Es geht nicht um eine DB, sondern um den jeweiligen SQL-Server (Firebird, IB7, Oracle usw.) . Unterstützt der irgendwas nicht, Pech gehabt. Nur der Vollständigkeit halber.

Jo, mit IBexpert geht das insoweit ganz gut. Die Server-Version kannst Du da seit kurzem auch auswählen. Ich habe heute damit schon 3mal meine DB neu angelgt, mit kleinen Änderungen. :mrgreen: Tja, wenn Du alles nützen willst (UDF, Stored Procedures usw.) wirst Du halt abhängig von irgendjemand. :?!?:

bis11 - Di 11.02.03 20:45

Das finde ich jetzt aber doof, denn ich möchte nicht abhängig werden. Ich würde gerne die SQL-Skripte zum erstellen von Tabellen und einfügen von Inhalten auf mehrere Datenbanken haben. Wenn's nicht geht, muß ich damit leben.

Hintergrund für meine Frage, ich bin gerade dabei an einem Konzept für ein Programm, welches ich nicht auf eine Datenbank festmachen wollte. Ich würde gerne dieses Programm für mehrere Datenbanken anbieten, so dass sich der Käufer keine neue Datenbank kaufen muß.

hansa - Di 11.02.03 20:52

Das ist ja auch gut so. Dann benutze nichts spezifisches, bleibe oder benutze Firebird und verkaufe das ganze für viel Geld. 8) Ich kenne keinen, der mit seinem Programm den ganzen Datenbankmarkt abdeckt.

bis11 - Di 11.02.03 20:57

Ich wollte ja auch nicht den ganzen Datenbankmarkt abdecken. Ich wollte nur die gängisten Datenbanken wie MSSQL, MySQL, Interbase, Firebird, Oracle und Access abdecken.

Lemmy - Mi 12.02.03 09:35

Hi,

bis11 hat folgendes geschrieben:

Ich wollte ja auch nicht den ganzen Datenbankmarkt abdecken. Ich wollte nur die gängisten Datenbanken wie MSSQL, MySQL, Interbase, Firebird, Oracle und Access abdecken.

Das funktioniert aber nicht! Neben den unterschiedlichen Implementierungen vom SQL-Standard hast Du das Zugriffs-Problem. Klar gibt es Komponenten, die alles können, aber dann hast Du wieder das Problem, denn der kleinste gemeinsame Nenner gibt vor, was funktioniert.
Spezielle Methoden die Performance o.ä. bringen kannst Du dann nicht einsetzen, weil es die anderen DBMS nicht unterstützen....

Grüße
Lemmy

bis11 - Mi 12.02.03 13:39

Ich muss euch mal ganz ehrlich was sagen, das finde ich nicht gut. Also muss ich mich auf eine festlegen oder für alle die passenden befehle mit ins Programm aufnehmen. Ich danke euch erstmal für eure Hilfe. Ich werde mir da mal etwas überlegen.

Udontknow - Mi 12.02.03 15:11

Du hast aber auch Probleme. Warum forderst du denn nicht gleich, ein und denselben Quellcode mit allen möglichen Compilern compilierbar zu machen?
Es sind eben Sprach- respektive Systemunterschiede vorhanden, basta. Willst du für möglichst alle RDBMS offen sein, darfst du nichts spezifisches (Prozeduren, Trigger, Foreign Keys, UDFs usw.) verwenden, das versteht sich doch von selbst.

Cu,
Udontknow

FaTaLGuiLLoTiNe - Mi 12.02.03 15:14

Im Grossen und Ganzen habt ihr ja recht aber wenn's echt nur um das reine Erstellen und Beladen von Tabellen geht (keine Indizes usw) und wenn keine exotischen Datentypen verwendet werden, sollte es gehen. Oder gibt es irgendeine Datenbank die sich SQL - fähig schimpft und nicht mal ein INSERT oder CREATE kann? Und darum ging's doch.

Also, meine Firma bietet schon Proggies an, die auf MS SQL genauso wie auf Informix und Oracle laufen, und Access Kunden haben wir glaub ich auch; auch MySQL wird wohl jetzt mit im Boot sein. Nur die CREATE - Befehle müssen wir halt teilweise wg. der Datentypen noch auf das jeweilige DBMS abstimmen. Damit ist doch schon ein ganz guter Teil des Marktes abgedeckt, oder nicht ?!?

bis11 - Mi 12.02.03 15:20

@FaTaLGuiLLoTiNe
Genau so habe ich das gemeint.

@Udontknow
Wenn Du etwas weiter oben einen meiner Beträge ließt, da habe ich gesagt, ich habe noch nie mit Triggern oder ähnlichem gearbeitet.

Udontknow - Mi 12.02.03 15:33

Zitat:

Ich muss euch mal ganz ehrlich was sagen, das finde ich nicht gut.

Zitat:

@Udontknow
Wenn Du etwas weiter oben einen meiner Beträge ließt, da habe ich gesagt, ich habe noch nie mit Triggern oder ähnlichem gearbeitet

Schön, sei es drum. Was also findest du nicht gut?

Cu,
Udontknow

bis11 - Mi 12.02.03 15:42

Zitat:

Ich muss euch mal ganz ehrlich was sagen, das finde ich nicht gut.

Zu dem Zeitpunkt habe ich das so verstanden, das es garnicht geht. Selbst nichtmal mit einfachsten CREATE und INSERT Befehlen.

FaTaLGuiLLoTiNe - Mi 12.02.03 15:59

Kommen wir dann mal zur Lösung Deines eigentlichen Problems :

Du willst also Deine komplette Datenbank entladen und in einer Datei speichern, ohne dass Du die Struktur der DB im Quelltext hinterlegst. Das solltest Du mit den TSession und TQuery Komponenten hinbekommen.

Diese Komponenten bieten Funktionen, um Alias- und Tabellennamen auszulesen (TSession.GetTableNames / TSession.GetAliasNames). Wenn Du die hast, kannst Du einfach auf jede Tabelle eine Abfrage machen und aus der Ergebnismenge die Feldtypen und -grössen (TField.DataType / TField.Size) auslesen.

Jetzt hast Du alle Informationen für Dein CREATE zusammen und kannst auch vernünftige INSERT - Anweisungen erzeugen.

Hoffe das war verständlich und dem Thema angemessen.

bis11 - Mi 12.02.03 16:27

Ich danke Dir für diesen Lösungsansatz. Ich werde da mal etwas mit rumexperementieren.

Mehr als einen Lösungsansatz wollte ich doch garnicht.

BIG THX

hansa - Mi 12.02.03 18:21

Hi bis11,

muß mich doch nochmal zu Wort melden. Das ganze ist nicht so einfach. Ich vermute, Du willst einfach nur die grundlegenden Datendefinitionen aus der DB auslesen :?: Daß die dann an die jeweilige DB angepaßt werden müssen, ist ja jetzt geklärt. Um ein SQl-Script zu erstellen, daß so etwas bewerkstelligt, benutze ich IBexpert. Dort gibt es einen Menüpunkt "extract Metadata". Dann kann man noch sagen, ob man nur die Trigger will oder was anderes. Auch wird noch gefragt, ob auch die Daten mitgeschleppt werden sollen, oder nicht.

Ich benutze das z.B., um die DB umzubauen und zu testen. Wenn es jetzt mit UDF oder Domains (z.B. bei Oracle) Ärger gibt, mußt Du die Scripte eben umbauen, das Delphi Programm wahrscheinlich sowieso. Dann löschst Du die vielleicht vorhande DB, nicht unregistern, läßt das Script laufen und basta. Dann meckert nur noch Delphi.

bis11 - Mi 12.02.03 19:45

Hi Hansa,

ich habe Dir doch schon gesagt, dass ich nicht mit Triggern oder sonstigen arbeite. Der Vorschlag von FaTaLGuiLLoTiNe ist nur dazu da um eine Tabellenstruktur auszuelesen und dann diese Tabellenstruktur in eine neue Datenbank zu übernehmen. Mir ist schon seit einigen Posting klar, das ich das nicht so einfach machen kann.

Du solltest wissen, dass ich es immer gerne etwas anderst haben möchte als die anderen. Ich errinnere Dich mal an den Thread mit dem erstellen der Interbase-Datenbank mit einem Delphiprog und nicht über die IBConsole.

Udontknow - Mi 12.02.03 21:46

So, jetzt muss ich mich auch noch mal zu Worte melden:

Mit dem IB-Expert kannst du alle möglichen Metadaten extrahieren. Dies schliesst auch Tabellendefinitionen mit ein. Du würdest also dann ein SQL-Script ausgeben lassen können, daß dir sämtliche Tabellen erstellt, so wie sie in der DB sind, aus der du die Metadaten extrahiert hast. Da es bei den Feldtypen zwischen den einzelnen RDBMS so gut wie keine Unterschiede gibt, solltest du auf keine grösseren Schwierigkeiten stossen.

Du musst also nicht unbedingt FatalGouillotines Vorschlag folgen und etwas eigenes proggen.

Cu, :)
Udontknow

bis11 - Mi 12.02.03 22:01

Das ist mir klar, dass ich nichts eigenes proggen muß, wenn ich den IBExpert benutze.

1.) Ich kann den IBExpert meines Wissen nicht auf jede Datenbank anwenden.

2.) Brauche ich diese Funktion in einem Programm direkt und will das nicht über ein anderes Programm machen.

Wie gesagt, ich arbeite noch an dem Konzept. Deshalb brauche ich erstmal alle Informationen die ich bekommen kann. Deshalb ist der Vorschlag von FaTaLGuiLLoTiNe für mich im Moment das sinnvollste.

Udontknow - Mi 12.02.03 22:31

Moment, moment! Du musst das Script doch nur ein einziges Mal erstellen lassen, nämlich dann, wenn deine DB-Struktur feststeht. Falls du also gerade auf einer Interbase-DB entwickelst, kannst du das Script erstellen und es in deinem Programm ausführen lassen. Damit könntest du dann die Struktur der DB herstellen. Den Daten-Im/Export in den Tabellen an sich könntest du mit einem Clientdataset bewerkstelligen.

Cu,
Udontknow

bis11 - Mi 12.02.03 23:08

Das ist richtig, nur was ist, wenn jemand ein Warenwirtschaftssystem auf Oracle oder Interbase hat und nun das System erweitern möchte auf einen Online-Shop. Dann müsste er das Warenwirtschaftssystem mit den ganzen Daten nochmals eingeben für MySQL, da meines Wissens ich nicht mit PHP auf eine Oracle-Datenbank zugreifen kann. Oder er macht es von irgendeiner anderen Datenbank.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!