Hallo...

Ich hatte letzlich eine Situation, wo ich eine Asbach uralte Version zum Laufen gebracht hätte wollen... Die QT sind im GIT eingescheckt. Die Datenbank nicht. (7GB) Die leere Datenbankstrutur ist im GIT. Zum Testen brauche ich aber Daten. Im Laufe der Zeit sind Strukturänderungen passiert die nicht mehr zum QT passen...normal.
Jetzt habe ich überlegt wie ich die Datenbank (ZIP 300MB) zur Version hinterlege. Direkt ins GIT?

Welche Möglichkeiten kommen da in Frage? Wie macht ihr sowas?

Danke...

Warum die ganze Datenbank ins GIT?
Bei Datenbank-Änderungen werden bei uns die Scripte zur Erstellung der Datenbank neu erzeugt. Diese Scripte kommen dann ins GIT.

Sofern es spezielle Daten (z.B. Basis-Konfiguration für die Anwendung) in der DB gibt, könnte man die als Export (XML, CSV, ...) sichern und ins GIT laden. Aber nicht die ganze DB. Das ergibt für mich keinen Sinn.

Hallo,
was ist es denn für eine DB?
Unter Firebird hilft es z.B. einfach eine Sicherung zu erzeugen und zu zippen (7zip).
Da die Sicherung keine Indizes enthält, ist sie i.d.R. viel kleiner als die ursprüngliche DB.
Unter FB kann man auch mit IBExpert die komplette DB als Script exportieren.

Danke...

Zitat:

Bei Datenbank-Änderungen werden bei uns die Scripte zur Erstellung der Datenbank neu erzeugt.

...diese Scripte habe ich auch für jede Datenbankänderung...und auch noch im GIT.
Ich will aber ein Downgrade der Datenbank mit Daten um alte Revisionen laufen lassen zu können.

USER:
"Das hat aber früher funktioniert!"
...ich will beweisen das das nicht so ist. Das geht aber nur mit der DB die zum QT paßt.

Zitat:

Unter Firebird hilft es z.B. einfach eine Sicherung zu erzeugen und zu zippen (7zip).

...ich habe eine Sicherung, gezippt 300MB.

Zitat:

was ist es denn für eine DB?

MSSQL

Mir ist es aber zu viel die ganze DB, bei Änderungen, einzuschecken. Deshalb die Frage.

Klingt für mich eher danach, dazu eine separate Sicherung der DB "irgendwo" geordnet abzulegen. Im GIT hat das mMn nichts zu suchen.

Du wirst das Problem ja bei fast jeder DB-Änderung haben. Ich würde da eher den DB-Export mit Datum und zugehöriger Revision, separat speichern. Eventuell mit allen notwendigen lauffähigen Programmen, damit solche Prüfungen sehr schnell durchgeführt werden können.

Zitat von haentschman:

USER:
"Das hat aber früher funktioniert!"
...ich will beweisen das das nicht so ist. Das geht aber nur mit der DB die zum QT paßt.

Kenne ich gut...

Aktuell überarbeite ich die Seupterstellung, Plan ist aktuell auch ein SVN Repository zu erstellen (bzw. ist schon da) und dort die relevanten Daten einzuchecken (also auch exe und Datenbankdatei) und dann den Autobuilder den Rest machen zu lassen. Aktuell funzt es noch, aber ich habe keinen Plan wie groß das Repository nach ein paar Versionen wird. Notfalls müsste ich dann mal einen cut machen und das Repository neu aufsetzen

Zitat:

Klingt für mich eher danach, dazu eine separate Sicherung der DB "irgendwo" geordnet abzulegen

...das probiere ich grad aus. Ins GIT kommt dann nur ein Link direkt auf das Datenbank ZIP. Das müßte reichen um die Datenbank wiederherzustellen.

FileName:
Firma_20200204_1616_1008_0.zip
=
Firma_Datum_Uhrzeit_DBVersion_DBPatch.zip

...vorzugsweise den Timestamp des Releases.

Danke.

Bei uns wird die gesamte Datenbank aus Scripten erzeugt. Inklusive eventueller Grunddaten, die in der Datenbank vorliegen *müssen*, damit die Anwendung funktioniert. Allerdings sind da nur ein paar wenige Datensätze. Durch die Skripte + Grunddaten kann ich jeder Zeit eine funktionierende leere Datenbank herstellen, wie sie der Kunde bekommt, wenn er ganz neu anfängt. Das liegt alles im Git. Die Skripte haben aber nur ein paar MB (wenn überhaupt).

Was für mich nicht ins Git gehört, wäre zum Beispiel eine Datenbank mit Demodaten. Das geht für Git zu weit.

GIT LFS

Zitat:

GIT LFS

...habe ich schon mal gehört. In der Free Version gibt es nur 1GB ... gilt das für alle Files oder pro Commit?