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.

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

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ß

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 ?

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

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.

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

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 ?

bis11 hat folgendes geschrieben:

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 ?

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. Tja, wenn Du alles nützen willst (UDF, Stored Procedures usw.) wirst Du halt abhängig von irgendjemand.

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ß.

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

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.

Verstehe Dich schon, aber das ist 80% des Marktes

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

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.

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

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 ?!?

@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.

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

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.