Hi zusammen
@mikhal
Zitat:
Ich vermute mal, dass der
MySQL-Dienst auf dem alten Rechner lief, während du die Datenbank kopiert hast. Dabei ist sie dann wohl geschreddert worden.
Wie gesagt, das liegt länger zurück, so dass ichs nicht mehr zuverlässig nachvollziehen kann. Aber da der
MySQL-Dienst standardmässig jeweils automatisch mit dem System startet, ist das sehr wahrscheinlich so.
Zitat:
Ich hoffe, die Datenbank funktioniert noch auf dem alten Rechner, dann erstelle dort mal ein Backup und restore dieses Backup auf dem neuen Rechner.
Wohl eher nicht - müsste ich mal nachsehen, ob es sie da überhaupt noch gibt, inklusive Delphi. Wenn ich das Ding gleichzeitig mit dem neuen Rechner aufstarte, um ihn von dem letzteren aus anzusprechen,ist erst mal "Kaffeeholen" angesagt. Was 4GB vs 8GB
Ram und ein aktuellerer Prozessor etc. ausmachen, ist immer wieder bemerkenswert...
Auf dem alten Rechner hatte ich zwar schon damit begonnen, Bilder in die
DB einzulesen; nach Ergänzungen des
DB-Modells sind diese aber wieder weg. Das ist zumindest im Entwicklungsstadium des Programms (die
DB ist nur ein, wenn auch der wichtigste, Teil davon) noch kein Beinbruch. Die Quellen der eingelesenen Bilder bleiben in jedem Fall erhalten.
Die
DB enthält auch Felder für Textdateien wie
HTML-, CSS- und JavaScriptStrings. Wären diese bereits editiert worden, sähe das ganze wohl etwas anders aus...
@jumpi:
Zitat:
Ehrlich gesagt, wäre das das erste gewesen, was ich gemacht hätte, um festzustellen, ob das nur eine Tabelle betrifft, die vllt. kaputt ist oder aber alle, dann liegt ein systematischer Fehler vor.
Ich denke, das wäre das Vorgehen, wenn nicht von einer oder mehreren geschredderten Tabellen/
DB ausgegangen werden müsste und/oder wenn die
DB Daten enthalten würde, deren Quellen nicht in Dateiform oder als Backup vorliegen, wie zB. die von mir oben genannten Texte, und dringend versucht werden müsste, noch in der
DB/andern Tabellen vorhandene und erreichbare Daten zu retten.
So aber denke ich, dass ich das Problem sollte lösen können, wenn ich das
DB-Modell erneut in die
DB einlese, bzw. mir diese vom Modell neu erstelle lasse.
Dabei könnte sich allerdings ein weiterer Fallstrick ergeben. Das Modell wurde unter 32Bit auf meinem alten Rechner erstellt, danach auf den neuen Rechner kopiert und da mit der 64-Bit-Version von Workbench geöffnet.
Und da liegt jetzt genau das, was ich nicht wirklich weiss: wieviel Einfluss hat die Bittigkeit des Servers und Workbench auf das Resultat (die
DB)?
Workbench erstellt, wenn ich das bisher richtig verstanden habe, lediglich die
SQL-Syntax zum Erstellen der
DB, Tabellen, Primär- und Fremdschlüssel etc., umgesetzt wird das ganze dann vom Server. Das bedeutet, ich erhalte eine Datenbank mit der Bittigkeit des Servers. Ist diese Überlegung richtig?
@mikhal:
Zitat:
PS: Die Tabellenamen müssen in Hochkomma gesetzt werden.
Sorry, wenn ich da teilweise widerspreche. Wenn ich in HeidiSQL
SQL-Syntax entwerfe/teste: ja. Das macht auch Heidisql selbst so. Aber im Pascal-Code sieht das etwas anders aus:
Delphi-Quellcode:
SQLString := 'Insert Into Bildtabelle(Thumbnail, Bitmap, FolderID) Values (:BJpeg, :Workmap, :LIDFolder)';
FDQueryMain.SQL.Text := SQLString;
FDQueryMain.Params[0].Assign(Bjpeg);
FDQueryMain.Params[1].Assign(Workmap);
FDQueryMain.Params[2].AsString := LIDFolder;
FDQueryMain.ExecSQL(false);
Zumindeest unter DBExpress war das so. Ich hab mir unter Firedac auch schon die eine oder andere Beispielanwendung angesehen. Dass es da anders wäre als unter DBExpress, ist mir zumindest nicht aufgefallen. Und wenn doch, schlägt mir Delphi die
DB um die Ohren...
Gruss
Delbor
PS: Gerade nochmal nachgelesen:
Zitat:
Datenbank 32/64 bit, egal
Datenbankclient 32 / 64 bit passend zum aufrufenden Programm
Das sollte so hinkommen.