Tabelle existiert nicht

[Delbor]

Hi zusammen

Nachdem von den da angesprochenen Problemen das letzte, die vermisste Tabelle, übriggeblieben ist, mach ich mal einen neuen Thread auf.
Die Fehlermeldung, notabene bei offener Verbindung und nachweislich existierender Tabelle:

Zitat:

Im Projekt ContentMasterDXE8.exe ist eine Exception der Klasse EMySQLNativeException mit der Meldung '[FireDAC][Phys][MySQL] Table 'contentmasterdata.kategorien_tabelle' doesn't exist' aufgetreten.

In der Hoffnung, mehr zu erfahren über das, was so abläuft, hab ich eine FDMoniFlatFileClientLink-Komponente auf dem Datenmodul abgelegt. Und das hat mir dann doch noch was genützt - allerdings erst, nachdem ich FDConnectionMySql.ConnectionDefName festgelegt und meine bisherige temporäre Connection deaktiviert hatte.

Die Monitor-Komponente erzeugt standardmässig ein Tracefile. Ich hab das Ding umbenannt und den Pfad in meinen Anwendungsordner verlegt; die so erzeugte txt-Datei finden interessierte im Anhang. Geöffnet sollte sie eventuell in einem Memo ohne Wordwrap oder einer vergleichbaren Umgebung(Notepad etc).

Was mir erstmal auffällt:

Zitat:

. mysql_get_client_info [Ver="5.5.9"]
. mysql_init
. mysql_options [option=1, arg=0]
. mysql_real_connect [host="localhost", user="root", passwd="***", db="contentmasterdata", port=3306, clientflag=198158]
. mysql_get_server_info [Ver="5.7.9-log"]
. mysql_set_character_set [cs_name="utf8"]

Mit mysql_get_client_info nehme ich mal an, ist die libmysql.dll gemeint. Tatsächlich liegen im Windowsverzeichnis zwei der Dinger. Ich hatte allerdings gehofft, wenn ich Vendorlib der Connectionkomponente explizit im OI angebe, dass dann auch diese benutzt wird - da hab ich offensichtlich falsch gedacht.

Interessant wird es ab Zeile 297: Ab da sind die Tabellen aufgelistet, die ich per Show Tables vom Server anfordere.

Dazu muss erstmal gesagt werden: Nach der Installation des Servers habe ich sämtliche Serverdatenbanken, sprich, das komplette Datadir nach F:\Databases1 kopiert - und eben nicht verschoben, damit ich die Originale noch habe, falls irgendwas schiefgeht. Und genau da liegt meine DB "contentmasterdata". Der Server kann also die Infos, die er mir per "Show Tables" zurückliefert, nur von da haben.
Und jetzt wirds geradezu spannend, fast so, wie bei Kommissar Maigret oder Hercule Poirot 8-) :da liegt auch die so hartnäckig vermisste Tabelle 'contentmasterdata.kategorien_tabelle'!

Allerdings: Es gibt unter MySQL nicht nur eine Inidatei, sondern meines Wissens mindestens drei (3)!

In C:\ProgramData\MySQL sind dies:

• MySQL Server 5.7my_2016-04-27T07-29-12.ini und (datadir=C:/ProgramData/MySQL/MySQL Server 5.7\Data)
• MySQL Server 5.7my_2016-04-20T14-20-39.ini und (datadir=C:/ProgramData/MySQL/MySQL Server 5.7\Data)

in C:\ProgramData\MySQL\MySQL Server 5.7
my.ini (datadir=F:\Databases 1)
Kursiv und in Klammern jeweils die Pfadangabe zum Data-Verzeichnis, wie sie in den einzelnen Ini's angegeben ist.

Was mich etwas (stark) verblüfft, ist, dass MySQL in mehreren verschiedenen Inidateien den Datadir-Pfad ablegt und nicht etwa 2 Pfade (Serverpath & Userpath) bereithält

So, wie ich das sehe, würde es genügen, wenn ich die Pfadangaben so abändere, dass sie dahin zeigen, wo nebst den Serverdatenbanken ach meine DB liegt. Oder gibt es dabei noch zusätzlich etwas zu beachten?

Eines ist sicher: ohne den 'guten alten' SQLMonitor wäre ich jetzt noch mit meinen Ratespielchen beschäftigt...

Gruss
Delbor

[jaenicke]

Ich meine mich zu erinnern (schreibe unterwegs am Handy), dass auch im Installationsverzeichnis im Unterverzeichnis data eine my.ini liegt. Welche benutzt wird und welches datadir benutzt wird sieht man ja leicht im Process Monitor auch ohne das log aus mysql.

[Delbor]

Hi jeanicke

Danke für den Hinweis! Ich hab da gerade mal nachgesehen - das müsste demnach C:\Program Files\MySQL sein. Da liegt tatsächlich eine C:\Program Files\MySQL\MySQL Server 5.7\mydefault.ini. Die enthält aber auf 22 Zeilen gerade mal einen Eintrag.

Gruss
Delbor

[Delbor]

Hi zusammem

Nachdem ich nun in allen Inidateien des Servers meinen eigenen DB-Pfad angegeben habe und die bewusste Tabelle weiterhin vermisst wird, hab ich mal die libmysql.dll im Windowsverzeichnis gegen diejenige dder Sererinstallation ausgetauscht. Die Fehlermeldung kommt recht bald: "unterschiedliche Archidekturen...
Der Server hat 64Bit, die ersetzte libmysql hatte 32Bit. Und die neu eingefügte latürnich auch 64Bit. Mit andern Worten: Ich darf den Server neu installieren. Oder sehe ich das falsch?

Eine dumme Frage noch: was ist der ProcessMonitor, von dem jaenicke sprach? Ich hab mal angenommen, dass er damit den SQL-Montior meint, aber da scheine ich falsch zu liegen...

Gruss
Delbor

[nahpets]

Process Monitor: https://technet.microsoft.com/de-de/...ssmonitor.aspx

[Delbor]

Hi nahpets

Danke für den link!

Gruss
Delbor

[Delbor]

Hi zusammen

Gestern habe ich nach langem Kampf endlich den MySQL-Server in der richtigen 32Bit-Version neu installiert. Enfant terrible waren einige MySQL-Dateien, die bei der Deinstallierung nicht entfernt wurden (und das waren nicht die, die ich per Hand verschoben hatte), und die dazu führten, dass zwar der Server installiert wurde,startete, sich aber gleich danach wieder verabschiedete.
In der neuen Installation gibts nur 2 Inidateien: die my.ini, die den DataDir-Pfad enthält und die Default-Ini.

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.

Mein Programm vermisst die bewusste Tabelle immer noch, liefert mir aber (wie gehabt) eine Liste der in der DB vorhandenen Tabellen per "Show Tables".
Vorbehaltlich der beiden unterschiedlichen libmysql-Dateien im Windows-Verzeichnis müsste der 'Fehler' also an der Konfiguration in FireDac liegen.
Ausser ConnectionDefName und DriverId habe ich überall die Defaulteinstellungen - die Embarcadero-Tutorials geben keinen Hinweis darauf, dass andere Einstellungen, zB. in FetchOptions, wichtig wären.

Ich frag mich also immer noch: wo liegt der Fehler?

Gruss
Delbor

[jobo]

sorry, ich blick nicht mehr durch, was alles verschoben, zurückkopiert, neuinstalliert, 32 / 64 bit und soweiter ist.

Nebenbei, Datenbankdateien verschieben als Backup-/Sicherungskonzept wäre nicht mein Ansatz, wenn ich nicht genau weiß, was ich tue. Im allgemeinen gibt es Highlevel-Verfahren um Datenbanken zu sichern und wieder herzustellen, je nach DB System gibt es entsprechende Tools bzw. Beschreibungen der Hersteller. Die Erfindung von API als konsistentem Zugriffsverfahren auf Daten oder Programmteile ist ja auch nicht aus Spaß geschehen. Auch wenn es DB Systeme gibt, die wirklich alle Daten in einer einzigen Datei halten, auch wenn es mit mySQL möglich ist/ war, hier einfach mit Copy/Paste zu arbeiten, mir scheint, da ist bei Dir was schief gelaufen.

Mein Ansatz wäre nun mangels Durchblick folgender:
Die fragliche Tabelle mit mysql werkzeug, also SQL Befehlen löschen und wieder herstellen (zunächst nur DDL), dann die Daten wieder einfügen. Alles so basic wie möglich, Kommandozeile, SQL Befehle, jeden Schritt soweit möglich mit Hilfe von Dictionary Abfragen prüfen. Also z.B. :
SQL abfrage im Repository nach vorhandenen Tabellen
> Tabelle wird angezeigt
> Tabelle zur Probe abfragen
SQL Befehl Drop table <böseTabelle>
SQL abfrage im Repository nach vorhandenen Tabellen
> Tabelle wird (hoffentlich) nicht mehr angezeigt
> Tabelle trotzdem zur Probe abfragen
SQL Befehl Create Table <guteTabelle>
SQL abfrage im Repository nach vorhandenen Tabellen
natürlich bis hin zum Create auf Fehlermeldungen achten und sofort nachforschen (ohne weiter zu machen), was die Fehlermeldung in Deinem Zusammenhang für Ursachen haben könnte.
Notfalls in speziellen mySQL Foren Rat holen zur Bereinigung eines korrupten Repositories
usw.

Und:
Warum sollte ein Client bei einer Tabelle im Zugriff eine Ausnahme machen und diese anders behandeln als andere Tabellen? Deine Vermutung bezüglich der Zugriffskomponenten scheint mir nicht plausibel.

[Delbor]

Hi Jobo

Vielen Dank für deine Antwort! Sie hat mich auf einige Details aufmerksam gemacht, die ich zwar irgendwo im Hnterkopf hatte, die mir aber nicht wirklich bewusst waren.

Zitat:

sorry, ich blick nicht mehr durch, was alles verschoben, zurückkopiert, neuinstalliert, 32 / 64 bit und soweiter ist.

• Auf meinem Rechner läuft Win10/64Bit
• Deshalb hab ich ursprünglich MySQL64-Bit installiert.
• Mein Programm ist eine 32Bit-Anwendung
• So hab ich jetzt MySQL64 wieder deinstalliert und
• MySQL32 installiert.

Zum verschieben von Dateien:

• Standardmässig wird das Dataverzeichnis auf C\: Programmdata\MySQLServer(...).Data angelegt. Da befinden sich die ServerDatenbanken(performannce_schema,mysql etc.)
• Diese da liegenden Daten habe ich in mein Verzeichnis F:\Databases 1 kopiert (Da ist auch genügend Platz vorhanden). Ich mach das nicht zum ersten mal.
• Dieses Vorgehen geht auf eine Empfehlung hier in diesem Forum zurück und hat auf meinem alten Rechner einwandfrei funktioniert.
• Um Sicherzustellen, das der Server im ursprünglich angelegten Verzeichnis keine Daten mehr ausliest, habe ich die da liegenden Daten in ein Verzeichnis ..\Data\Archiv verschoben.

Entstanden ist die Datenbank auf meinem alten 32Bit-Rechner. Als ich mir die aktuelle Maschine (Win10/64Bit) zulegte, kopierte ich die DB via Heimnetzwerk von der alten auf die neue Kiste. Dann hab ich sie in MySQL-Workbench geöffnet. Die war wie der installierte Server 64Bittig. Somit wäre denkbar, dass auch die Dateien jetzt für 64Bit angelegt sind, nachdem ich das Modell abgeändert/ergänzt hatte und davon eine DB erstellen liess und die somit von einem 32Bit-Programm nicht mehr gelesen werden kann.

Zitat:

Mein Ansatz wäre nun mangels Durchblick folgender:
Die fragliche Tabelle mit mysql werkzeug, also SQL Befehlen löschen und wieder herstellen (zunächst nur DDL), dann die Daten wieder einfügen. Alles so basic wie möglich, Kommandozeile, SQL Befehle, jeden Schritt soweit möglich mit Hilfe von Dictionary Abfragen prüfen. Also z.B. :

Ich denke, mit dem Neuerstellen der Tabelle hast du recht. Allerdings gehe ich davon aus, dass mein Programm nicht nur diese, sondern alle andern Tabellen der DB nicht findet/finden würde. Eine Bestätigung dessen hab ich zwar nicht, ausser dass das Programm auf meinem alten 32Bit-Rechner einwandfrei funktioniert hat. Sicher, ich könnte die AV abfangen und weitermachen. Aber wenn diese Tabelle nicht gefunden wird, gibt es keinen Grund,weshalb die andern Tabelle gefunden werden sollten. Dies daher, weil die SQL-Anweisungen von MySQL-Workbench automatisch (und somit mehrfach geprüft), erstellt wurden.
Aber eben: eine 64Bit-Version von Workbench erstellt auch eine 64Bit-Datenbank - das fängt schon bei den Datentypen an.

Somit wäre denkbar, dass auch die Dateien jetzt für 64Bit angelegt sind, nachdem ich das Modell abgeändert/ergänzt hatte und davon eine DB erstellen liess und die somit von einem 32Bit-Programm nicht mehr gelesen werden kann.

Zitat:

Warum sollte ein Client bei einer Tabelle im Zugriff eine Ausnahme machen und diese anders behandeln als andere Tabellen?

Genau deshalb versuche ich gar nicht, ob auf andere Tabellen ein Zugriff möglich wäre.

Zitat:

Deine Vermutung bezüglich der Zugriffskomponenten scheint mir nicht plausibel.

Aufgrund der Tutorials auf den Embarcadero-Seiten, insbesondere jenes über das Query, muss ich dir wohl recht geben - andrerseits bin ich immer noch dabei, mich in Firedac einzuarbbeiten. Und das ist wesentlich komplexer, als es seinerzeit die BDE war.

Gruss
Delbor

[mikhal]

Zur MySQL 64-Bit Installation: Gab es im MySQL-Verzeichnis kein WOW64-Unterverzeichnis? Bei einer Firebird-Installation wird ein solches Verzeichnis angelegt, dort findet man dann die 32-Bit Client-DLL FBCLIENT.DLL. Ich könnte mir Vorstellen, dass es ein solches Verzeichnis bei MySQL auch gibt.

Daraus resultierend kann man eigentlich die Überlegung vergessen, dass ein 64-Bit-Datenbank-Server eine 32-Bit-Datenbank verändert.

Stellen sich mir die nächsten Fragen: Findest du fehlende Tabelle mit deinem Admin-Tool? Wie hast du die Datenbank von deinem alten Rechner auf den neuen Rechner transferiert - als Backup oder als Kopie?

Grüße
Mikhal

[jobo]

Normalerweise ist es so (seit es 64 Bit Windows Betriebssysteme gibt):
Datenbank 32/64 bit, egal
Datenbankclient 32 / 64 bit passend zum aufrufenden Programm
Anwendung 32 / 64 bit benötigt einen Datenbankclient (Treiber) der gleichen Bittigkeit

Wenn Du also ein 32 Bit Programm baust, brauchst Du einen 32 Bit Datenbanktreiber, egal wie die Bittigkeit der DB ist.

Analog für ein 64 Bit Programm

[Delbor]

Hi Mikhal

Zitat:

Gab es im MySQL-Verzeichnis kein WOW64-Unterverzeichnis?

Nein - sowas kenne ich nur von Windows. Im übrigen: nicht alle von dem msi-Installer angelegten Programme waren 64Bit.

Zitat:

Wie hast du die Datenbank von deinem alten Rechner auf den neuen Rechner transferiert - als Backup oder als Kopie?

Per Heimnetzwerk hab ich das entsprechende Verzeichnis geöffnet und da <Verzeichnis verschieben> gewählt - glaube ich wenigstens. Das ist auch schon wiedder etwas her.
Wie auch immer - ein via MySQL erstelltes Backup wars sicher nicht.

Zitat:

Findest du fehlende Tabelle mit deinem Admin-Tool?

Jein - Als Admintool verwende ich neben dem angeprochenen Workbench noch HeidiSQL. Letzters kennt zwar eine Datenbank contentmasterdata, aber deren Tabellen nicht. Wobei die entsprechende Connection angelegt wurde, als noch MySQL64 installiert war.
Workbench hingegen zeigt mir die Tabellennamen an, nicht aber Colums, Indexes und Foreignkeys, die eigentlich"mit im Angebot" wären.

Gruss
Delbor

[Delbor]

Hi jobo

Zitat:

Wenn Du also ein 32 Bit Programm baust, brauchst Du einen 32 Bit Datenbanktreiber, egal wie die Bittigkeit der DB ist.

Dann war das nicht wirklich das Problem. Bleibt noch die Versionsnummer der libmysqsl, die für mein Empfinden deutlich unter der des Severs lag (5.5.x / 5.7.x). Aber ob das in jedem Fall problematisch ist, entzieht sich meiner Kenntnis.

Gruss
Delbor

[nahpets]

Langsam kommt mir der Verdacht, dass die interne Verwaltungsstruktur der Datenbank geschreddert wurde.

MySQL hat, wie auch andere Datenbanken, ein INFORMATION_SCHEMA

Ein Select * from INFORMATION_SCHEMA.TABLES sollte Klarheit über die vorhandenen Tabellen bringen.

Über ein Select * from INFORMATION_SCHEMA.COLUMNS sollten dann die Spalten zu finden sein.

Zur Fehlereingrenzung:
Was bringen die beiden folgenden SQL für ein Ergebnis?

SQL-Code:

select * from INFORMATION_SCHEMA.TABLES where TABLE_NAME = 'kategorien_tabelle';

select * from INFORMATION_SCHEMA.COLUMNS where TABLE_NAME = 'kategorien_tabelle';

Stimmen die Ergebnisse mit dem erwarteten überein?

Wenn nein, welche Abweichungen zum Erwarteten gibt es?

[jobo]

Zitat:

Zitat von nahpets (Beitrag 1365056)

Langsam kommt mir der Verdacht, dass die interne Verwaltungsstruktur der Datenbank geschreddert wurde.

Eben, deswegen habe ich vorgeschlagen, probehalber eine Tabelle zu löschen und neu anzulegen. Meinetwegen auch eine ganz neue, die es nicht bereits gibt und den Zugriff darauf testen.

[nahpets]

Ja, meiner Meinung nach sollte hier systeamtisch vorgegangen werden.

Show Tables liefert ja ein Ergebnis.

Alles was da rauskommt wird der Reihe nach mit Select * from abgefragt.

Bei Fehlern werden die erstmal nur protokolliert.

Sind alle Abfragen durch, wird geprüft, ob es bei den Fehlern irgendwelche Zusammenhänge gibt.

Zur Fehleranalsyse sollte das Information_Schema dann genauestens durchforstet werden.

Hier stehen die von MySQl genutzten / benötigten Dateien drin INFORMATION_SCHEMA FILES.

Nötigenfalls wird ein Select * from INFORMATION_SCHEMA.FILES gemacht und geprüft, ob die dort aufgeführten Dateien auch alle an der dort aufgeführten Stelle zu finden sind.

Was wo zu finden sein sollte, müsste hier genauer aufgeführt sein: NDB Notes

[Delbor]

Hi zusammen

Ich hab die beeiden von Nahpeds geposteten Statements mal getestet. Dazu hab ich in einem Frame eine Prozedur angelegt:

Delphi-Quellcode:

procedure TServerInfoFrame.TestShowTables;
  var SqlString : String;  i : Integer;
begin
  SqlString :=  'select * from INFORMATION_SCHEMA.COLUMNS where TABLE_NAME = kategorien_tabelle'; // <=
  FDMySQLDml.FDMySQLQueryInfo.SQL.Text := SqlString;
  FDMySQLDml.FDMySQLQueryInfo.Open;
  FDMySQLDml.FDMySQLQueryInfo.First;
  i := 1;
  while (not FDMySQLDml.FDMySQLQueryInfo.Eof) do
  begin
    Memo1.Lines.Add('*************'); FDMySQLDml.FDMySQLQueryInfo.Fields.Fields[0].AsString;
    FDMySQLDml.FDMySQLQueryInfo.Next;
    inc(i);
  end;
  FDMySQLDml.FDMySQLQueryInfo.Close;
// select * from INFORMATION_SCHEMA.TABLES where TABLE_NAME = 'kategorien_tabelle';

end;

Den SQL-Sring hab ich dann wahlweise mit dem erste, bzw. dem zweiten Statement belegt.
Die Fehlermeldungen:

Zitat:

Im Projekt ContentMasterDXE8.exe ist eine Exception der Klasse EMySQLNativeException mit der Meldung '[FireDAC][Phys][MySQL] Unknown column 'kategorien_tabelle' in 'where clause'' aufgetreten.

Zitat:

Im Projekt ContentMasterDXE8.exe ist eine Exception der Klasse EMySQLNativeException mit der Meldung '[FireDAC][Phys][MySQL] Unknown column 'kategorien_tabelle' in 'where clause'' aufgetreten.

Gruss
Delbor

[mikhal]

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.

Ich hoffe, die Datenbank funktioniert noch auf dem alten Rechner, dann erstelle dort mal ein Backup und restore dieses Backup auf dem neuen Rechner. Dann sollten sich deine Probleme (hoffentlich) in Luft auflösen.

Grüße
Mikhal

PS: Die Tabellenamen müssen in Hochkomma gesetzt werden.

[nahpets]

Du suchst hier nach Tabelleninhalten, von daher muss das wohl eher so aussehen:

Delphi-Quellcode:

SqlString := 'select * from INFORMATION_SCHEMA.COLUMNS where TABLE_NAME = ''kategorien_tabelle'' ';

Oder so:

Delphi-Quellcode:

SqlString := Format('select * from INFORMATION_SCHEMA.COLUMNS where TABLE_NAME = %s',
[QuotedStr('kategorien_tabelle')])';

[Jumpy]

Zitat:

Zitat von Delbor (Beitrag 1365047)

Zitat:

Warum sollte ein Client bei einer Tabelle im Zugriff eine Ausnahme machen und diese anders behandeln als andere Tabellen?

Genau deshalb versuche ich gar nicht, ob auf andere Tabellen ein Zugriff möglich wäre.

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.

[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... :-D


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... :P
Ohne dir nahe treten zu wollen... Warum hältst du an MySQL fest? Fast :wink: alle deine Beiträge kämpfen mit MySQL. Alle DBMS haben fast die gleichen Funktionen. Der Unterschied liegt imho im Handling. :thumb: 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. :roll: 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... :roll:

[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

[Jumpy]

[OT]

Zitat:

"though"(Gedanke,Idee).

"though" ist in dem Zusammenhang aber eher mit "trotz" oder "obwohl" zu übersetzen. Dann wird der Satz für dich vllt. auch klarer.

Gedanke/Idee dagegen ist eigentlich "thought", also noch ein t hinten dran.
[/OT]

[Delbor]

Hi Jumpi

Danke für die Übersetzungshilfe. So wie ich das sehe, bestätigt mir das: die Tabellen sind zwar da, können vom Server aber nicht gelesen werden.

Gruss
Delbor

[Jumpy]

Die Tabellen sind in dem Sinne da (zumindest nach deinem Error-Log) als das die Tabellendatei .frm da ist, aber im Data-Dictionary der Datenbank ist kein Hinweis darauf zu finden.

Vielleicht kannst du als erstes die Datei erstmal entfernen (umbenennen) dann eine gleich Aufgebaute leere Tabelle mit dem entsprechenden Namen neu erzeugen (über irgenein Datanbank-Tool). Anschließend die Dabei generierte .frm datei mit der alten Version austauschen.
Wichtig dabei, das Create Statement muss genau den Aufbau der alten Datei/Tabelle wieder spiegeln.

[Delbor]

Hi Jumpy

Es gab zwei Möglichkeiten für mich, vorzugehen: MySQL zu deinstallieren und erneut im Verzeichnis F\: Database 1 zu instalieren (anstelle von C\: Programme). Damit hätte ich den Server auf einer Platte, die zumindest zur Zeit gross genug ist. Ich hab mich aber jetzt dazu entschieden, diee Tabellen meiner bisherigen DB zu löschen (und vorher sicherheitshalber den Server herunterzufahren). Anschliessend soll die DB anhand meines Workbench-Modells neu erstellt werden. Die Syntax wäre dieselbe.

Gruss
Delbor