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 :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