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.