Tabelle existiert nicht

[Delbor]

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.

[p80286]

Ab hier

Zitat:

Den Inhalt des originalen DataDir-Verzeichnisses hab ich wieder in eine eigenes DataDir kopiert. Um sicher sein zu können, dass MySQL nicht auf das originale Dataverzeichnis zugreift, habe ich da ein Archivverzeichnis angelegt und die Originaldateien dahinverschoben.
Das heisst: MySQL ist jetzt so installiert und konfiguriert, wie es sein sollte. Einzig im Windowsverzeichnis befinden sich 2 Versionen der libmysql, wobei sich die ältere 'vor' der mit der aktuellen Versionsnummer befindet.

habe ich mich geistig verabschiedet.
Das klingt mir nach zuviel Kuddelmuddel.
Hier wäre eine vollständige Bestandsaufnahme angesagt. Und jedes Detail müßte geprüft werden, nach dem Motto "welches Verhalten habe ich unter welchen Bedingungen".

Gruß
K-H

[mikhal]

Hallo Delbor,

die "Bittigkeit" des Servers hat keinen Einfluss auf die Struktur der Datenbank, sonst könntest du nie mit einem 64-Bit Client auf einen 32-Bit Datenbank-Server zugreifen oder mit einem 32-Bit-Client auf einen 64-Bit Server.

Deshalb fragte ich ja, ob du ein Backup hast, das du auf dem neuen Server via Restore einspielen kannst.

Habe ich vor ein paar Tagen hier bei uns realisieren müssen, allerdings mit Firebird. Mein Entwicklungsrechner hat lokal einen 64-Bit Firebird Server installiert, der "alte" Server, auf dem das System schließlich laufen sollte, ist ein virtualisierter 32-Bit Windows 2003 Server. Backup vom Entwicklungsrechner wurde einwandfrei inklusive der Notwendigen, bereits erfassten Daten (und dazu gehörten Blobs) restauriert. Die Datenbank läuft auf dem 32-Bit-System einwandfrei und sehr performant.

Grüße
Mikhal

[MichaelT]

Fährst du auf dem alten Server einen Inno-DB cluster?

Ist das Inno-DB oder ISAM?

Du hast auf jeden Fall ein 5.7.9 Server und eine 5.5.9 Client library ... (log)

Mich würde wundern wenn die anderen Tabellen noch funktionieren im Fall von InnoDB.

Liegt bei dir im C:\Program Files\MySQL\MySQL Server\data eine Datei ibdata1, iblogfile*, diese wären der 'System tablespace' und die Logfiles....

Die Datenbanktabellen während die *.idb files, während die .frm files die Sturkurbeschreibung wären. Show tables geht auf die frm files, wenn ich mich recht erinnere.

Eine InnoDB kann man nicht so einfach rumkopieren. In der Not kann man die DB mal ins \data reinkopieren zumindest bei ISAM sollte das gehen.


Du solltest mal eine CHECK TABLE machen ...

-----

Eine XY-bit Applikation braucht eine XY Bit Client DLL ansonsten hast du in der Regel Kommunikation über Netzwerk. Damit ist die Bitigkeit all dessen was sich am 'Server' abspielt egal.

[Delbor]

Hi zusammen

@Michael:

Zitat:

Ist das Inno-DB oder ISAM?

Dass ist Inno-DB.

Zitat:

Du hast auf jeden Fall ein 5.7.9 Server und eine 5.5.9 Client library ... (log)

Unter MySQL64 war dies so. Dieaktuelle libMysql hat die Version 5.7.1.17, ebenso der Server (Auskunft des Explorers). 5.7.9 war die 64Bit-Version

Zitat:

Mich würde wundern wenn die anderen Tabellen noch funktionieren im Fall von InnoDB.

Vorbehaltlich eines Übersetzungsfehlers meinerseits tun sie das auch nicht.
Zu dieser Aussage bringt mich ein Blick in die err - Datei. Die ist aus der Oberfläche der Workbench aufrufbar:

Zitat:

2017-03-22T00:21:40.969972Z 8 [Warning] InnoDB: Cannot open table contentmasterdata/htmltabelle from the internal data dictionary of InnoDB though the .frm file for the table exists. Please refer to http://dev.mysql.com/doc/refman/5.7/...eshooting.html for how to resolve the issue.

Meines schlechten englisch wegen informierte ich mich bei LEO über die Bedeutung von "though"(Gedanke,Idee). Für mich sagt dieser Eintrag also aus, dass die .frm-Datei zwar vorhanden ist, aber nicht gelesen werden kann. Ich denke schon, dass das im Ansatz nicht falsch ist (?).
Tja, und mit solchen Einträgen sind auch alle andern Tabellen meiner DB vertreten.

Zitat:

Liegt bei dir im C:\Program Files\MySQL\MySQL Server\data eine Datei ibdata1, iblogfile*, diese wären der 'System tablespace' und die Logfiles....

Da liegen die nicht mehr. Die habe ich alle nach F:\ Database1 verschoben, wo auch meine DB liegt - Das habe ich auch auf meinem alten Rechner so gemacht, nachdem damals eine benutzerdefinierte Installation des Servers bei mehreren Versuchen in die Hose ging und ich deswegen schliesslich entnerft komplett installierte. Ich durfte mich im Anschluss daran über jede Mengen Connectoren und anderen Kram "erfreuen" (Eben über 'Immer Ärger mit Harry...äh MySQL').

Zitat:

Die Datenbanktabellen während die *.idb files, während die .frm files die Sturkurbeschreibung wären. Show tables geht auf die frm files, wenn ich mich recht erinnere.

Danke für die Info!

Zitat:

Eine InnoDB kann man nicht so einfach rumkopieren. In der Not kann man die DB mal ins \data reinkopieren zumindest bei ISAM sollte das gehen.

Auch auf meinem alten Rechner hatte ich das so gemacht, und zwar gezwungenerweise, weil auf C: gar nicht genügend Platz für eigene Datenbanken ist. Auf dem alten Rechner war C: nur eine Partition und hätte von daher wohl vergössert werden können; auf der neuen Maschine ist dies aber eine eigene Platte mit gerade mal 256GB(SSD).
Andrerseits aber fällt mir jetzt auf, dass ich das eigentlich gewusst habe.

Ich lege die err-Datei mal als txt-File bei. Vielleicht entdeckt ja jemand etwas, das mirentgangen ist.

Gruss
Delbor

[nahpets]

Die Fehlermeldungen bedeuten für mich:

Im Datadictionary der Datenbank stehen die Tabellen drin. Die Datenbank kann aber nicht die zugehörigen Datendateien finden.

Daraus schließe ich: Das Hin- und Herkopieren der Datenbank ist gründlich in die Hose gegangen.

[haentschman]

Hallo Delbor...
Ohne dir nahe treten zu wollen... Warum hältst du an MySQL fest? Fast alle deine Beiträge kämpfen mit MySQL. Alle DBMS haben fast die gleichen Funktionen. Der Unterschied liegt imho im Handling. Aus den Beiträgen entnehme ich das du wahrscheinlich die Datenbank mit umkopieren zerstört hast...
Beipiel:
Eine Firebird Datenbank ist eine Datei um Gegensatz zu den einzelnen Dateien von MySQL. Persönlich käme mir das nicht ins Haus. Diese Firebird Datenbank kann man kopieren und funktioniert sowohl mit dem Server als auch auf einem USB Stick. Das nenne ich "universell"...

Warum tust du dir das an...

[Delbor]

Hi haentschman

Ziel der Anwendung ist es, Daten für eine Webserveranwendung bereitzustellen. Der Hoster bietet 2 Datenbanken an: MySQL und MSSQL. Letzteres ist erst seit einiger Zeit in einer nicht zusätzlich kostenplichtigen Version erhältlich.

FireDac gibt mir da neue Möglichkeiten: MySQLite könnte für die Anwendung zum Einsatz kommen, müsste die Daten aber nach MySQL/MSSQL exportieren können.

Ein Umbau auf SQLite könnte ich mir grundsätzlich eher vorstellen als ein solcher auf MSSQL Express. So, wie ich das sehe, ist letzterer gegenüber MySQL doch anders aufgebaut. Soweit ich das bis jetzt verstanden habe, könnte ich die Syntax von MySQL mit nur wenigen Änderungen übernehmen.
Andrerseits ist es mir im Moment vor allem wichtig, meine Anwendung auf dem neuen Rechner zum laufen zu bringen. So, wie ich das bis jetzt sehe, ist sie schon beinahe "fürs erste fertig", wenn ich einige Sachen vorerst auslasse/delegiere (andere Programme tun lasse).

Gruss
Delbor

[mikhal]

Hallo Delbor,

du erwähntest bereits mehrfach, dass du der englischen Sprache nicht wirklich mächtig bist.

Hast du deutschsprachige Unterlagen zu MySQL? Schau dir mal diesen Link zu einem deutschen Handbuch zu MySQL an (CHM-Format).

Grüße
Mikhal

[Delbor]

Hi mikhal

Vielen Dank für den Link. Ich hatte - oder habe immer noch - einen Link zu einem Deutschen Handbuch, aber daswar uralt. Den link hab ich zur Zeit nicht zur Hand, aber das Merkmal der Seiten war silbergrauer Hintergrund und blau Schrift.
Die verlinkte Seite hingegen scheint mir auf den ersten Blick viel jünger zu sein.

Gruss
Delbor