Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error (https://www.delphipraxis.net/183300-xe7-firedac-tfdconnection-gettablenames-auf-firebird-%3D-abstract-error.html)

Perlsau 30. Dez 2014 06:24

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 TFDConnection.GetTableNames versucht habe:

Delphi-Quellcode:
Function TInfoFireBird.Tabellen: Boolean;
Var
  Liste : TStrings;

begin
  Liste := TStrings.Create;
  Try
    Try
      FBCon.GetTableNames('','','',Liste,[osMy],[tkTable]);
Das liefert mir leider eine Fehlermeldung zurück, obwohl die Syntax korrekt zu sein scheint (kein Compilerfehler):
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:
FBCon.GetTableNames('','','%',Liste,[osMy],[tkTable]);
Katalog- und Schemanamen gibt es ja bei Firebird nicht, das sind glaub ich Begriffe aus MySQL bzw. MsSQL :?:

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:
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;
In der Hilfe ist ein Fehler: Die Syntax der Methode wird mit drei Strings als Parameter dargestellt, unten im Beispiel werden jedoch vier leere Strings als Parameter übergeben. Drei sind aber richtig, bei vieren kommt ein Compilerfehler.

mikhal 30. Dez 2014 06:33

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. Siehe z.B. hier.

Grüße
Michael

Lemmy 30. Dez 2014 06:43

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.

Perlsau 30. Dez 2014 07:01

AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
 
Zitat:

Zitat von mikhal (Beitrag 1284951)
Hilft zwar nicht konkret bei deinem Problem, aber hast du schon versucht, die Tabellennamen über die Metadaten zu ermitteln. Siehe z.B. hier.

Moin Mikhal, das war mein nächster Gedanke. Allerdings weiß ich noch nicht, ob dieser Weg die Unterscheidung zwischen Tabellen und Views ermöglicht ... Mit GetTableNames soll das ja angeblich gehen ...

Zitat:

Zitat von Lemmy (Beitrag 1284952)
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.

Moin Lemmy, das werd ich jetzt gleich mal versuchen ... So, jetzt weiß ich mehr:

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?

Sir Rufo 30. Dez 2014 07:05

AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
 
**hüstel**

Schau mal in die Doku Delphi-Referenz durchsuchenTStrings

Du willst bestimmt eine Delphi-Referenz durchsuchenTStringList-Instanz erzeugen ;)

Perlsau 30. Dez 2014 07:09

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

Perlsau 30. Dez 2014 07:50

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

Bernhard Geyer 30. Dez 2014 09:09

AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
 
Hat wirklich der User die Tabellen angelegt oder sieht er sie nur?
http://docwiki.embarcadero.com/Libra...y.ObjectScopes

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.

Perlsau 30. Dez 2014 10:08

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.

Sir Rufo 30. Dez 2014 10:22

AW: XE7 FireDac TFDConnection.GetTableNames auf Firebird = abstract error
 
Eine gänge Alternative sollte wohl
Delphi-Quellcode:
[osMy, osOther]
sein, dann bekommt man auf jeden Fall alle Tabellen ausgenommen die SystemTabellen.


Alle Zeitangaben in WEZ +1. Es ist jetzt 23:11 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz