Tabelle existiert nicht

[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