Guten Abend miteinander,
ich habe mich soeben auf diesem Forum registriert da ich ein Datenbankprojekt im Kopf habe was ich gerne mit Lazarus und Firebird realisieren möchte.
Jetzt hab' ich einige Vorab-Fragen und die Erste ist vermutlich schon saublöd:
1.) Ich wollte Firebird benutzen weil man die Datenbank als Datei (z.B. MeineDatenbank.FDB) in einem Verzeichnis liegen sieht und ich überlege ob es sinnvoll ist die Datenbank zum Zweck der Sicherung einfach an einen anderen Ort zu kopieren/zwischendurch auf DVD zu brennen. Mit Access hab' ich das so gemacht und mit SQLite geht das meine ich auch. Funktioniert das auch mit Firebird? Es gibt ja ein Sicherungstool um Backup's zu machen. Sollte man das bevorzugen?
Das Sicherungstool führt zur zweiten Frage:
2.) Es sollen auch Bilder (*.jpg/*.jpeg) gespeichert werden. Dafür nimmt man wohl den Datentyp BLOB. Werden mit dem Sicherungstool auch Blob's mit vollem Informationsgehalt, sprich das kpl. Bild so wie es in die Bank geladen wurde, gesichert?
2.a) Speichert man in der DB besser nur einen Link zum Bild?
3.) Für die Nutzung mit Lazarus: Nimmt man die in der Lazarus-Installation vorinstallierten Komponenten oder ist das zeosDB-Package besser?
4.) Gestern habe ich mit dem isql-Tool ein wenig mit output gespielt. Das hat auch soweit funktioniert. Gibt es einen Befehl mit dem man die csv-Datei schließen kann? Immer wenn ich die Datei im Explorer löschen wollte , kam die Meldung, dass die Datei noch geöffnet sei. Wenn ich den isql-Editor (die Eingabeaufforderung) zugemacht habe, konnte ich löschen. Output öffnet die Datei und man schreibt hinein, aber wie schließt man sie?
Jetzt hab' ich für's Erste genug belästigt. Für Antworten danke ich im Voraus.
Viele Grüße
Firethustra
Datenbank verschieben
Moderator: thorben.braun
- martin.koeditz
- Beiträge: 474
- Registriert: Sa 31. Mär 2018, 14:35
Hallo Firethustra,
herzlich willkommen im Forum.
zu 1.
Datenbanken zu Sicherungszwecken einfach zu kopieren ist sehr riskant. Damit hast du schnell eine korrupte Datenbank. Wenn du auf Nummer Sicher gehen willst, verwende nbackup oder gbak.
zu 2.
Die Tools sichern alle Daten einer DB komplett. Mit passenden Schaltern lässt sich das natürlich ändern. Aber standardmäßig wird alle gesichert, sodass eine Wiederherstellung das gewünschte Ergebnis zurückliefert.
zu 3.
Hierzu müssen sich die Lazarus-Experten melden.
zu 4.
ISQL hat exklusiven Zugriff auf die CSV-Datei. Dieser wird erst entfernt, wenn isql beendet wird. Ggf. reicht es auch die Datenbankverbindung zu trennen. Habe ich noch nicht ausprobiert.
Es werden sich sicherlich noch einige auf deine Fragen melden.
Gruß
Martin
herzlich willkommen im Forum.
zu 1.
Datenbanken zu Sicherungszwecken einfach zu kopieren ist sehr riskant. Damit hast du schnell eine korrupte Datenbank. Wenn du auf Nummer Sicher gehen willst, verwende nbackup oder gbak.
zu 2.
Die Tools sichern alle Daten einer DB komplett. Mit passenden Schaltern lässt sich das natürlich ändern. Aber standardmäßig wird alle gesichert, sodass eine Wiederherstellung das gewünschte Ergebnis zurückliefert.
zu 3.
Hierzu müssen sich die Lazarus-Experten melden.
zu 4.
ISQL hat exklusiven Zugriff auf die CSV-Datei. Dieser wird erst entfernt, wenn isql beendet wird. Ggf. reicht es auch die Datenbankverbindung zu trennen. Habe ich noch nicht ausprobiert.
Es werden sich sicherlich noch einige auf deine Fragen melden.
Gruß
Martin
Martin Köditz
it & synergy GmbH
it & synergy GmbH
- martin.koeditz
- Beiträge: 474
- Registriert: Sa 31. Mär 2018, 14:35
Achja, noch was zum Ablegen der Bilder:
Ob du die Bilder direkt in die DB schreibst oder im Dateisystem ablegst und nur einen relativen Pfad in der DB vorhälst ist dir überlassen. Meist wird letzteres durchgeführt. Allerdings müssen dann die DB und das Dateisystem gesichert werden.
Gruß
Martin
Ob du die Bilder direkt in die DB schreibst oder im Dateisystem ablegst und nur einen relativen Pfad in der DB vorhälst ist dir überlassen. Meist wird letzteres durchgeführt. Allerdings müssen dann die DB und das Dateisystem gesichert werden.
Gruß
Martin
Martin Köditz
it & synergy GmbH
it & synergy GmbH
Ergänzend zu
1) Backuptools sind hier grundsätzlich vorzuziehen, da diese auch im laufenden Betrieb sichern können und kompaktere Outputs erstellen.
Ein Copy scheitert fast immer, da in bereits kopierten Bereichen wieder Änderungen geschrieben werden die auf noch zu kopierende Bereiche massive Auswirkungen haben. Im Laufenden Betrieb verbietet sich das sowieso.
Hier sei noch zu ergänzen:
Steckt die DB in einer VM und die VM wird extern gesichert, hat das in den meisten Fällen eine korrupte DB zur folge da die Firebird noch keinen VSS-Writer hat und der übergeordnete Backup die DB-Bereiche partiell vor Veränderungen schützt.
2) das ist Geschmackssache. Man muss sich nur über die Konsequenzen Gedanken machen. Man sollte die Bilder oder auch Dokumente in einer separaten Tabelle mit einem ID-Feld und dem BLOB speichern damit nicht bei jedem Zugriff auf Daten unnötigerweise das Bild wieder geladen wird. Das Problem wird dabei die Anwendung sein, da meist ein Dokument nur per Dateiname angezeigt werden kann und dann wieder der Inhalt erst in einer Datei gespeichert werden muss.
Wie z.B. bei Web-Anwendungen in denen meist nur Links (Urls) verwendet werden.
3) Wenn es eine integrierte Lib gibt ist diese immer vorzuziehen. Der Umweg wäre sonst den ODBC-Treiber der allerdings nicht mehr weiterentwicklet wird oder falls mögliche den .Net-Treiber zu verwenden.
zu 4)
Im Sinnen von Transaktionen sollte die CSV frei werden, wenn man Commit durchführt. Alles andere macht eigentlich keinen Sinn, denn im laufenden Betrieb wäre das sonst schädlich.
1) Backuptools sind hier grundsätzlich vorzuziehen, da diese auch im laufenden Betrieb sichern können und kompaktere Outputs erstellen.
Ein Copy scheitert fast immer, da in bereits kopierten Bereichen wieder Änderungen geschrieben werden die auf noch zu kopierende Bereiche massive Auswirkungen haben. Im Laufenden Betrieb verbietet sich das sowieso.
Hier sei noch zu ergänzen:
Steckt die DB in einer VM und die VM wird extern gesichert, hat das in den meisten Fällen eine korrupte DB zur folge da die Firebird noch keinen VSS-Writer hat und der übergeordnete Backup die DB-Bereiche partiell vor Veränderungen schützt.
2) das ist Geschmackssache. Man muss sich nur über die Konsequenzen Gedanken machen. Man sollte die Bilder oder auch Dokumente in einer separaten Tabelle mit einem ID-Feld und dem BLOB speichern damit nicht bei jedem Zugriff auf Daten unnötigerweise das Bild wieder geladen wird. Das Problem wird dabei die Anwendung sein, da meist ein Dokument nur per Dateiname angezeigt werden kann und dann wieder der Inhalt erst in einer Datei gespeichert werden muss.
Wie z.B. bei Web-Anwendungen in denen meist nur Links (Urls) verwendet werden.
3) Wenn es eine integrierte Lib gibt ist diese immer vorzuziehen. Der Umweg wäre sonst den ODBC-Treiber der allerdings nicht mehr weiterentwicklet wird oder falls mögliche den .Net-Treiber zu verwenden.
zu 4)
Im Sinnen von Transaktionen sollte die CSV frei werden, wenn man Commit durchführt. Alles andere macht eigentlich keinen Sinn, denn im laufenden Betrieb wäre das sonst schädlich.
Hallo.Firethustra hat geschrieben: ↑Mi 20. Jan 2021, 20:21 ...
4.) Gestern habe ich mit dem isql-Tool ein wenig mit output gespielt. Das hat auch soweit funktioniert. Gibt es einen Befehl mit dem man die csv-Datei schließen kann? Immer wenn ich die Datei im Explorer löschen wollte , kam die Meldung, dass die Datei noch geöffnet sei. Wenn ich den isql-Editor (die Eingabeaufforderung) zugemacht habe, konnte ich löschen. Output öffnet die Datei und man schreibt hinein, aber wie schließt man sie? ...
@Firethustra meint vielleicht den ISQL-Befehl:
OUTput [<filename>] -- schreibt die Ausgabe in die benannte Datei output
Ich gehe mal davon aus, dass @Firethustra seinen Firebird unter Windows laufen lässt.
Und in der Tat verhält es sich so, dass dort (Windows) die gerade erzeugte OUTput-Datei unter laufender Sitzung und unter Verwendung des Dateiexplorers nicht gelöscht werden kann.
Sie kann aber bei laufender Sitzung (weiterhin laufen lassendes ISQL-Tool) sehr wohl gelöscht werden, indem wieder zur Standardausgabe umgeschaltet wird. Diese Umschaltung erreicht man mit der erneuten Eingabe von OUTput.
Kurz und knapp also so:
Code: Alles auswählen
...
SQL> OUTPUT '/home/gerd/Firebird/Datenbanken/anschriften.csv';
SQL> SELECT ...FROM ... WHERE;
SQL> OUTPUT;
SQL>
Unter Linux muss man nicht mit OUTput auf die Standardausgabe umschalten.
Dort kann sowohl die gerade mit
Code: Alles auswählen
SQL> OUTPUT '/home/gerd/Firebird/Datenbanken/export_anschrift.csv';
Code: Alles auswählen
SQL> SELECT ...FROM ... WHERE;
Viele Grüße
Gerd
ISQL Version: LI-V5.0.1.1469
Linux Mint 22 Cinnamon 6.2.7
Linux Mint 22 Cinnamon 6.2.7
-
- Beiträge: 3
- Registriert: Mi 20. Jan 2021, 19:45
Hallo,
vielen Dank für Eure Antworten.
Was das Verschieben angeht, so würde die Datenbank von 5 Leuten gleichzeitig benutzt und spätestens zum Feierabend sind alle weg, sodass man sie kopieren und auslagern könnte.
Das zweite "Output" war's! Es ist genauso wie es Gerd beschrieben hat.
Auf Linux hab' ich es noch nicht probiert. Auf MacOS auch noch nicht, aber wird schon so sein, dass man dort das zweite Output nicht benötigt.
Vielen Dank für die Antworten
Viele Grüße
Volker
vielen Dank für Eure Antworten.
Was das Verschieben angeht, so würde die Datenbank von 5 Leuten gleichzeitig benutzt und spätestens zum Feierabend sind alle weg, sodass man sie kopieren und auslagern könnte.
Code: Alles auswählen
SQL> OUTPUT '/home/gerd/Firebird/Datenbanken/anschriften.csv';
SQL> SELECT ...FROM ... WHERE;
SQL> [color=#FF0000]OUTPUT[/color];
Das zweite "Output" war's! Es ist genauso wie es Gerd beschrieben hat.
Auf Linux hab' ich es noch nicht probiert. Auf MacOS auch noch nicht, aber wird schon so sein, dass man dort das zweite Output nicht benötigt.
Vielen Dank für die Antworten
Viele Grüße
Volker
- martin.koeditz
- Beiträge: 474
- Registriert: Sa 31. Mär 2018, 14:35
Hallo Firethustra
Siehe auch Punkt 1 von bfuerchau:
Gruß
Verlass dich nicht darauf, dass dann bereits alle Daten auf die HDD geschrieben wurden. Solange noch "hängende" Daten / Transaktionen vorhanden sind, hast du zu diesem Zeitpunkt bereits eine korrupte DB.Was das Verschieben angeht, so würde die Datenbank von 5 Leuten gleichzeitig benutzt und spätestens zum Feierabend sind alle weg, sodass man sie kopieren und auslagern könnte.
Siehe auch Punkt 1 von bfuerchau:
Also reines Kopieren ist mit Vorsicht zu genießen.Backuptools sind hier grundsätzlich vorzuziehen, da diese auch im laufenden Betrieb sichern können und kompaktere Outputs erstellen.
Gruß
Martin Köditz
it & synergy GmbH
it & synergy GmbH
-
- Beiträge: 3
- Registriert: Mi 20. Jan 2021, 19:45
Guten Morgen zusammen,
ich habe mal eine Frage zur Benutzung bzw. Administration von Firebird auf'm Mac.
Ich nutze "bigsur" und habe festgestellt, dass flamerobin nicht mehr läuft. flamerobin vermutlich 32bit und das läuft nicht mehr. Welche OpenSource Alternativen gibt es, womit arbeitet Ihr?
Vielen Dank
Volker
ich habe mal eine Frage zur Benutzung bzw. Administration von Firebird auf'm Mac.
Ich nutze "bigsur" und habe festgestellt, dass flamerobin nicht mehr läuft. flamerobin vermutlich 32bit und das läuft nicht mehr. Welche OpenSource Alternativen gibt es, womit arbeitet Ihr?
Vielen Dank
Volker
Flamerobin ist windowsbasiert und läuft daher nicht für Mac.
Ansonsten findest du die Tools hier:
https://firebirdsql.org/en/third-party-tools/
Hier gibts auch eine Macversion:
https://www.sql-workbench.eu/macos-binary.html
Ansonsten findest du die Tools hier:
https://firebirdsql.org/en/third-party-tools/
Hier gibts auch eine Macversion:
https://www.sql-workbench.eu/macos-binary.html