Tabelle existiert nicht

[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 von nahpets:

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:

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

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.