![]() |
Datenbank: Firebird • Version: 2.5 • Zugriff über: FireDac
XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
Moin allerseits :cyclops:
Ich will mein IbDac zurück :wall: Seit ein paar Tagen arbeite ich nun remote an einem Rechner im Ruhrgebiet, bis der Programmierer Mitte Januar aus'm Urlaub zurück ist. Im Verlauf des Projekts muß ich alle Tabellen zahlreicher Datenbanken verschiedenster DBMS auslesen, analysieren und die so gewonnenen Daten sichern, was ich im Falle einer Firebird-DB mit ![]()
Delphi-Quellcode:
Das liefert mir leider eine Fehlermeldung zurück, obwohl die Syntax korrekt zu sein scheint (kein Compilerfehler):
Function TInfoFireBird.Tabellen: Boolean;
Var Liste : TStrings; begin Liste := TStrings.Create; Try Try FBCon.GetTableNames('','','',Liste,[osMy],[tkTable]); Im Projekt ****.exe ist eine Exception der Klasse EAbstractError mit der Meldung 'Abstrakter Fehler' aufgetreten. Die drei leeren Strings sollen "normalerweise" beinhalten: ACatalogName, ASchemaName beschränken Tabellennamen auf den Katalog und das Schema. APattern ist das LIKE-Muster zum Filtern der Tabellennamen. Wenn ich als APattern das Like-Zeichen % eintrage, kommt dieselbe Fehlermeldung:
Delphi-Quellcode:
Katalog- und Schemanamen gibt es ja bei Firebird nicht, das sind glaub ich Begriffe aus MySQL bzw. MsSQL :?:
FBCon.GetTableNames('','','%',Liste,[osMy],[tkTable]);
Falls ich den Rechner dort zum Absturz bringe, muß ich den Nachbarn anrufen, der die Kiste dann neu startet :stupid: Das muß ich natürlich unter allen Umständen vermeiden, ist ja quasi eine Bewährungsprobe :oops: Die Verbindungsfunktion sieht so aus:
Delphi-Quellcode:
In der
Function TInfoFireBird.Verbinden: Boolean;
begin Try FBCon.Connected := False; FBCon.Params.Clear; FBCon.Params.Append('DriverID=FB'); FBCon.Params.Append('CharacterSet=UTF8'); FBCon.Params.Append('Database=' + DateiName); FBCon.Params.Append('User_Name=' + DBI.DbUser); FBCon.Params.Append('Password=' + DBI.DbPass); FBCon.Params.Append('ExtendedMetadata=True'); FBCon.DriverName := 'FB'; FBCon.Connected := True; Result := True; Except on e:exception Do Begin Result := False; Fehlertext := 'Fehler bei Verbindung mit "' + DateiName + '": ' + e.Message; End; End; end; ![]() |
AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
Hilft zwar nicht konkret bei deinem Problem, aber hast du schon versucht, die Tabellennamen über die Metadaten zu ermitteln.
![]() Grüße Michael |
AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
Hi,
EAbstractError deutet ja darauf hin, dass das Programm versucht eine Methode einer KLasse aufzurufen, die nicht implementiert ist (in einer abgeleiteten Klasse eine in der Elternklasse als abstract; eingeführte Methode). D.h. Du kannst da vermutlich übergeben was Du willst - ich vermute, dass der Weg der falsche ist... Sind die FireDAC Sourcen bei dir dabei? Dann könntest Du mal durchdebuggen und schauen wo es knallt. |
AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
Zitat:
Zitat:
In der Unit FireDAC.Comp.Client knallt es in der procedure TFDCustomConnection.GetTableNames, und zwar nach dem zweiten Try beim Versuch, die übergebene Liste zu leeren: AList.Clear; (Zeile 4764). Was stimmt denn mit meiner Liste nicht? |
AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
|
AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
Mithüstel :oops:
Natürlich muß es heißen Liste := TStringList.Create; Danke, Sir Rufo, Du bist einfach unersetzlich :thumb: Achso: Jetzt geht's natürlich :-D |
AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird : Parameter?
Die Sache ist allerdings noch nicht ganz gegessen: Wenn ich eine Datenbank angebe, die überprüft 17 Tabellen besitzt, bleibt die Liste dennoch leer. Leider ist die Dokumentation der Parameter von GetTableNames äußerst dürftig. Dennoch hab ich herausgefunden, daß man sich vom TFDPhysObjectScopes osMy nicht beirren lassen darf, denn damit erhält man 0 Tabellen, zumindest in allen Firebird-Datenbanken, die ich eben mal kurz damit getestet habe. Man muß dagegen osOther angeben, womit man die selbst angelegten Tabellen erfaßt. Vielleicht bedeutet das My ja, daß es für MySQL-Datenbanken gilt und nicht "my tables" :?::!::?: So von wegen intuitiv und so ...
Erwähnt sei das Ganze sozusagen der Vollständigkeit halber, wenn da mal jemand das gleiche Problem hätte ... |
AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
Hat wirklich der User die Tabellen angelegt oder sieht er sie nur?
![]() Bei MySQL könnte ich mir auch vorstellen das hier je nach Version die Kennzeichnung "Diese Tabelle hat der eingelockte User angelegt" nicht eindeutig/stabil bestimmbar ist. |
AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
Das weiß ich nicht, den mit osMy werden keine Tabellen gezählt. Muß ich mal bei mir zu Hause testen, derzeit meldet sich die Anwendung bei den diversen Datenbanken, die gezählt und analysiert werden sollen, natürlich mit SYSDBA und MASTERKE (bzw. mit den entsprechend geänderten Zugangsdaten, die ich hier aber nicht verrate :stupid:) an, sonst müßte man ja erstmal alle Tabellen händisch durchgehen und die jeweiligen Zugangsdaten eingeben, von denen ich derzeit gar nicht weiß, wo mein Auftraggeber sie abgelegt hat.
|
AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
Eine gänge Alternative sollte wohl
Delphi-Quellcode:
sein, dann bekommt man auf jeden Fall alle Tabellen ausgenommen die SystemTabellen.
[osMy, osOther]
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:03 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz