Guten Abend,
ich habe folgendes Anliegen.

Ich habe eine Datenbank lokal vorliegen "test.sql".
Den Inhalt dieser Datenbank möchte ich nun geordnet darstellen.

Man könnte sagen wie PhpMyAdmin.
Nur möchte ich das Ganze eben können, ohne mir z.B. XAMPP zu laden und dort die DB zu importieren.

Jetzt ist meine Frage, wie parse ich die Datenbank?
Gibt es dazu eine Komponente die das kann, oder muss ich das selbst bewerkstelligen?

Wie macht das PhpMyAdmin?
Ich stelle es mir schwer vor so eine Datenbank manuell zu parsen, weil evtl. ein Leerzeichen vorhanden sein könnte oder auch nicht.
Oder "Gänsefüßchen" statt Hochkomma und ander herum.

Könnt ihr mir da vielleicht einen Denkanstoß geben?

Ähm, wenn du eine xyz.sql Datei hast, dann hast du zu 123,45% keine Datenbank vor dir.

Das ist ungefähr so, als ob du eine Textdatei hast und sagst, ich habe hier eine Textverarbeitung.

Wie das phpMyAdmin macht?

Der verbindet sich zu einem SQL-Server und die Sprache dort heißt SQL, soll also heißen, der SQL-Server kann den Inhalt dieser .sql Datei verstehen und verarbeiten.

Es gibt noch die Möglichkeit MySQL embedded zu verwenden, aber Obacht vor der Lizenzfalle

Stimmt du hast recht xD
Natürlich ist es wenn ich eine .slq vor mir habe nur eine ganz normale Textdatei.

Ok ich denke ich werde den Inhat dann wohl ganz normal mit zahlreichen pos Abfragen parsen müssen.

Zitat von SyntaxXx:

Stimmt du hast recht xD
Natürlich ist es wenn ich eine .slq vor mir habe nur eine ganz normale Textdatei.
Ok ich denke ich werde den Inhat dann wohl ganz normal mit zahlreichen pos Abfragen parsen müssen.

Dateien mit der Endung *.sql enthalten in der Regel SQL-Befehle, die von einer Datenbank ausgeführt werden (sollen). Das können ebenso Insert-Befehle wie auch grundsätzliche Datenbank-Strukturen sein. Es müssen sich also nicht zwangsläufig darstellbare Daten in einer SQL-Datei befinden. Zudem hat jede Datenbank ihren eigenen SQL-Dialekt.

Um dir weiterhelfen zu können, wäre es sinnvoll, wenn du erst einmal berichtest, worum es überhaupt geht:

1. Was befindet sich in der SQL-Datei?
2. Was möchtest du erreichen?
3. eventuell noch: Wo hast du die Datei her?

Ich setze hier mal voraus, dass die vorliegende .sql Datei sowas ist, wie das was der alte MySQL Administrator als Backups erstellt hat. (Also Table Definitions und Inserts für alle Tabellen in einer großen Datei.):

Wenn es nur darum geht die Daten daraus zu lesen, lad dir dich einfach fix den MySQL Community Server runter. Dann den Inhalt der Datei dort als Script ausführen, und du hast die Datenbank als wirkliche Datenbank vorliegen. Von dort aus kannst du dann halt mit allem was MySQL verbinden kann darauf zugreifen. So lange du das DBMS oder das Programm dass die DB liest (vorausgesetzt es nutzt die libmysql.dll und/oder kann NUR MySQL lesen) nicht an Kunden weiter gibst, ist hier auch kein Lizenzproblem zu erwarten. Alternativ geht auch praktisch immer MariaDB statt MySQL - dann auch komplett ohne Lizenzgeschwurbel.

Ganz ehrlich, der Community Server ist 10x schneller runtergeladen und installiert als dein hypothetisches Programm die .sql Datei mit Pos() durchgeparsed hat. Wenn du dazu noch die Zeos-Lib (kostenfreie DB-Komponenten die auch mit MySQL prima können) installierst, steht dem eigenen Programm zum Daten migrieren nichts mehr im Wege. Bevor ich da mit Pos() und Konsorten ankäme... also da müsste ich mir schon mächtig einen trinken um mir den unnötigen Schmerz antun zu wollen.

@Medium

So wie ich die Lizenz-FAQ von MariaDB verstehe gibt es dort auch noch diese Lizenzproblematik.
Entschärft was die Client-Lib betrifft, aber noch da ...

https://kb.askmonty.org/en/licensing-faq/

Zitat:

Distributing a proprietary application with the MariaDB / MySQL server

When you are distributing your application together with MariaDB or MySQL you are bound (or can be seen to be bound by some lawyers) by the GPL if some of the following statements apply:

You are using GPL code from MySQL linked directly to your application. (Like the MySQL GPL client library).
Your application requires the MariaDB server to work and without the MariaDB server it doesn't start or it has very limited functionality.

Der Spaß hier ist jedoch, dass dieses 2. Statement von beiden, MySQL und MariaDB gemacht wird. Beide sind aber auch in der Praxis gegeneinander austauschbar, so dass für beide Fälle gilt: Es würde auch mit dem jeweils anderen DBMS gehen.

Ausserdem findet sich auf der von dir verlinkten Seite gleich oben folgender Text:

Zitat:

The new MariaDB client libraries for C and Java are distributed under the LGPL license, version 2.1 or later. The LGPL license allows you to distribute these MariaDB client libraries freely with any application.

The MariaDB client library included with the MariaDB server is also GPL version 2, but has a FLOSS exception that allows you to combine it with most other open source software, without conflicting with their license, even if that license is incompatible with the GPL. We do however recommend you to use the new client libraries for any non-GPL application.

Ergo: MariaDB ist, spätestens mit Benutzung der aktuellen Client Lib, immer ein Ausweg aus der MySQL Lizenz-Falle. Und so lange man es nur für interne / persönliche Tools benutzt, hat man damit ohnehin keine Last. Auch mit MySQL und dessen Lib. (Und zur MariaDB Lib gibt es auch noch die schöne Alternative UniDAC, zumindest für wenn man in Sprachen entwickelt, für die es das gibt. Und da gerade UniDAC eine ganze Latte an DBMS bedient, bindet man sein Programm nichtmals implizit an MySQL/MariaDB. Aber es geht halt auch kostenlos.)


Edit: Zudem sagt dein Zitat:

Zitat:

When you are distributing your application together with MariaDB or MySQL [...]

Das heisst: Wenn ich mein Programm mit einem der DBMS gebundled ausliefere, dann...! Sage ich dem Kunden aber: "Hey, ich empfehle dir MariaDB/MySQL runterzuladen und zu installieren", sieht das schon wieder alles anders aus. Selbst wenn ich dann im Auftrag die Einrichtung der DB erledige. Genau genommen könnte ich sogar das Runterladen und Installieren zum Bestandteil des Auftrages machen, womit es noch immer in den Verantwortlichkeitsbereich des Kunden fällt. Lasse ich zudem noch ein anderes DBMS zu, düfte sich Oracle schwer tun da etwas zu erwirken.
Letztlich hat das aber in diesem Thread hier nicht allzu viel zu suchen, da es ja scheinbar wirklich nur um ein kleines internes Tool geht, welches nicht für die Veräusserung an Kunden gedacht ist. Aber halt selbst wenn...