Tabellenfelder 2 versch. Datenbanken vergleichen

[Luckner]

Hallo,
ich möchte bestimmte Felder einer Tabelle aus Firebird und einer aus MS-Access miteinander vergleichen und die Unterschiede in einem DBGrid anzeigen. Mein Versuch (mit Fehlermeldung) ist folgender:

Delphi-Quellcode:

procedure TFrameRohwareLager.JvHTButton1Click(Sender: TObject);
begin
  DatamoduleAuftrag.DataModule2.ADOConnection1.Connected := false;
  DatamoduleAuftrag.DataModule2.ADOConnection1.connectionstring := 'Provider=Microsoft.Jet.OLEDB.4.0; Data Source = ' + ADOConnection + ' ; Persist Security Info=False;';
  DatamoduleAuftrag.DataModule2.ADOConnection1.Connected := true;

  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.Active := False;
  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.SQL.Clear;
  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.SQL.Add('select Art-Nr, Format, Numerierung from Artikel T2 INNER JOIN [Material-Stamm] on Artikel.[Mat-Nr] = [Material-Stamm].[Mat-Nr] ORDER BY Artikel.[Mat-Nr]');
  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.Open;

  DatamoduleRohwareLager.DataModule9.IBDatabaseRohwareBewegung.Connected := true;
  DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.Close;
  DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Clear;
  DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Add('select ROHWARENR, FORMAT, OBERMATERIAL from ROHWARESTAND T1 on T1.ROHWARENR = T2.[Art-Nr] where T1.FORMAT <> T2.[Format] OR T1.OBERMATERIAL <> T2.[Numerierung] order by ROHWARENR');
  DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.Open;
end;

Leider mit einer Fehlermeldung des SQL-Servers. Könnte mir Jemand helfen?
Danke und Gruß,
Luckner

[DeddyH]

Wer bringt welchen Fehler?

[Luckner]

Beim "JvHTButton1Click" kommt: "Syntaxfehler in JOIN-Operation"

Luckner

[DeddyH]

In der letzten SQL-Anweisung fehlt ja auch der JOIN (T2 ist gar nicht definiert).

[Frickler]

Zitat:

Zitat von Luckner (Beitrag 1398014)

Beim "JvHTButton1Click" kommt: "Syntaxfehler in JOIN-Operation"

Luckner

Unterstützt Firebird denn die Angabe von Feldnamen in eckigen Klammern? Ich dache, das wäre eine Access-Spezialität, die keine andere Datenbank hat.

[Luckner]

Stimmt. Habe es jetzt geändert, aber mit selben Meldung.

Delphi-Quellcode:

procedure TFrameRohwareLager.JvHTButton1Click(Sender: TObject);
begin
  DatamoduleAuftrag.DataModule2.ADOConnection1.Connected := false;
  DatamoduleAuftrag.DataModule2.ADOConnection1.connectionstring := 'Provider=Microsoft.Jet.OLEDB.4.0; Data Source = ' + ADOConnection + ' ; Persist Security Info=False;';
  DatamoduleAuftrag.DataModule2.ADOConnection1.Connected := true;

  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.Active := False;
  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.SQL.Clear;
  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.SQL.Add('select Art-Nr, Format, Numerierung from Artikel T2 INNER JOIN [Material-Stamm] on Artikel.[Mat-Nr] = [Material-Stamm].[Mat-Nr] ORDER BY Artikel.[Mat-Nr]');
  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.Open;

  DatamoduleRohwareLager.DataModule9.IBDatabaseRohwareBewegung.Connected := true;
  DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.Close;
  DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Clear;
  DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Add('select ROHWARENR, FORMAT, OBERMATERIAL from ROHWARESTAND T1 LEFT JOIN T2 on T1.ROHWARENR = T2.Art-Nr where T1.FORMAT <> T2.Format OR T1.OBERMATERIAL <> T2.Numerierung order by ROHWARENR');
  DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.Open;
end;

[Luckner]

Hallo Frickler,

Delphi-Quellcode:

  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.Active := False;
  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.SQL.Clear;
  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.SQL.Add('select Art-Nr, Format, Numerierung from Artikel T2 INNER JOIN [Material-Stamm] on Artikel.[Mat-Nr] = [Material-Stamm].[Mat-Nr] ORDER BY Artikel.[Mat-Nr]');
  DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.Open;

funktioniert. Benutze schon für andere Abfragen und greife mit der ADO-Komponnente direkt auf eine ACCESS-Datenbank. Für die JOIN-Anweisung habe ich die eckigen Klammern auch ausgelassen.

Luckner

[p80286]

(hab ich eigentlich schon mal gesagt, was ich von diesen Einzeilern halte?)

Hab ich es übersehen?
Das Datamodule9 hat gar keine DB mit dem es sich verbindet?
Und diese eckigen Klammern sind eine access-Spezialität. Aber wemm MS und DBs auf einander treffen gibt es die eine oder andere Eigenheit. Sonst könnte man ja die DB problemlos austauschen.

Wie wäre es wenn Du erst versuchst die Verbindung zu einer Datenbank auzubauen, und dann die zu der anderen?
Dann ist unter Umständen die Fehlersuche etwas einfacher?

Gruß
K-H

[Jasocul]

Hast du die SQL-Statements schon ohne Delphi geprüft?
Es wäre auch gut zu wissen, welches SQL-Statement den Fehler bringt.

Was mit auffällt:

Code:

select Art-Nr

Das müsste mMn in eckigen Klammern stehen.

[Delphi.Narium]

Dazwischen JOIN T2 fehlt der Tabellenname.

Das muss irgendwie so aussehen: JOIN Tabellenname T2

Wenn die Tabellen in beiden Datenbanken den gleichen Namen haben, wird's wohl Join Artikel T2 heißen müssen.

Wahrscheinlich wäre es dann dashier:

Delphi-Quellcode:

DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Add('select ROHWARENR, FORMAT, OBERMATERIAL');
DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Add('from ROHWARESTAND T1');
DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Add('LEFT JOIN Artikel T2');
DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Add('on T1.ROHWARENR = T2.Art-Nr');
DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Add('where T1.FORMAT <> T2.Format');
DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Add('OR T1.OBERMATERIAL <> T2.Numerierung');
DatamoduleRohwareLager.DataModule9.IBDataSetRohwareBestand.SelectSQL.Add('order by ROHWARENR');

[Luckner]

Das grosse Problem ist, dass ich auf die Firebird-Tabelle mit TDataset zugreife und auf die ACCESS mit einer ADO-Komponnente. Die Verknüpfung bekommen ich nicht hin.

Verbindung zu Firebird-Datenbank geht über "DatamoduleRohwareLager.DataModule9.IBDatabaseRohw areBewegung.Connected := true;"

Die einzelnen SQL-Statemens funktionieren für sich alleine gut.

Luckner.

[joachimd]

In der Regel dürfte es nicht funktionieren, über zwei verschiedene Datenbanken hinweg eine SQL-Abfrage zu machen. Die beiden wissen ja nichts voneinander.

[jobo]

Zitat:

Zitat von joachimd (Beitrag 1398033)

In der Regel dürfte es nicht funktionieren, über zwei verschiedene Datenbanken hinweg eine SQL-Abfrage zu machen. Die beiden wissen ja nichts voneinander.

Wenn das tatsächlich die Absicht des Codes sein sollte, dann ist es ein Irrweg, ja.
Die Statements aus dem Eröffnungsthread sehen jedenfalls unvollständig aus, ein Gemisch aus Join und Where Syntax.

Falls wirklich Access mit Firebird gejoined werden soll, dann würde ich das (wenn es leider nun mal da ist) in Access selbst machen:
- FB Tabelle oder Viewe in Access verlinken per ODBC
- Abfrage in Access aus Access Tabelle und Firebird Link erzeugen.
- Abfrage in der Anwendung öffnen (oder eben zur Probe gleich in Access)

[Delphi.Narium]

Bitte erkläre mal, was Du genau vorhast, irgendwie scheine ich das noch nicht so recht begriffen zu haben.

Willst Du quasi sowas machen?

SQL-Code:

select t1.ROHWARENR, t1.FORMAT, t1.OBERMATERIAL
from Accessdatenbank.ROHWARESTAND t1
LEFT JOIN Firebirddatenbank.Artikel t2
on t1.ROHWARENR = t2.Art-Nr
where t1.FORMAT <> t2.Format');
OR t1.OBERMATERIAL <> t2.Numerierung
order by ROHWARENR

Wenn ja, dann führe Dir mal diese Anleitung zu Gemüte: Importieren von oder Verknüpfen mit Daten in einer anderen Access-Datenbank

Beim Zugriff über ADO / ODBC könnte das, sofern ein entsprechender Treiber für Firebird eingerichtet ist, funktionieren.

Jobo beschreibt ja, wie es gehen sollte.

[himitsu]

Zitat:

Zitat von joachimd (Beitrag 1398033)

In der Regel dürfte es nicht funktionieren, über zwei verschiedene Datenbanken hinweg eine SQL-Abfrage zu machen. Die beiden wissen ja nichts voneinander.

Viele DBMS bieten Funktionen/Extensions an, wo man in der DB zu anderen DB oder gar anderen DBMS eine Verbindung aufbaut und Abfragen schicken kann.

z.B.
Cross-Server-Tabelle > Foreign Data Wrappers (permanent DB Link)
https://www.postgresql.org/docs/9.2/...tawrapper.html
https://wiki.postgresql.org/wiki/Foreign_data_wrappers

Cross-Server-Link > DB Link (temporär, old style)
https://www.postgresql.org/docs/9.3/static/dblink.html

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1398037)

Viele DBMS bieten Funktionen/Extensions an, wo man in der DB zu anderen DB oder gar anderen DBMS eine Verbindung aufbaut und Abfragen schicken kann.

Aber eher nicht über Delphi Datenmodule, oder?

[himitsu]

Zitat:

Zitat von jobo (Beitrag 1398038)

Aber eher nicht über Delphi Datenmodule, oder?

Doch.
FireDAC kann es

LocalSQL
FireDAC LocalSQL



Aber wie gesagt, mindestens eine der beiden DBMS kann sowas bestimmt auch serverseitig.
z.B. in MS-Access eine Verbindung zu Firebird aufbauen und dann im MS-Access die SELECTs zu beiden Datenbanken ausführen.

Bei den Foreign Data Wrappers in Postgres kannst du sogar beide SELECTs zusammen in einem JOIN ausführen und den "Vergleich" direkt im SQL und nicht erst clientseitig manuell erledigen.

[jobo]

Oh! Ich bin überrascht!
Ist aber dann dennoch nicht die von Dir genannte Technik einer heterogenen Datenbankverbindung zwischen verschiedenden DBMS.

[Luckner]

Mein Problem ist folgendes:
Es gibt 2 Programme. Das 1. basiert auf Access und es werden bestimmte Artikel in einer Tabelle eingetragen. Das 2. Programm ist auf Firebird aufgebaut. Es werden einige Artikel aus Programm 1 in 2 übernommen und gegebenfalls ergänzt. Obwohl sich die Artikel in Programm 1 nicht mehr ändern sollte, passiert es doch mal. Jetzt wäre es hilfreich, wenn man in bestimmten Abständen, eine Überprüfung starten könnte um die beiden Tabellen miteinander zu überprüfen, ob Artikel 1 immer noch die alten Eigenschaften hat.

Möglicherweise werde ich die Tabelle aus Access erst in eine temporäre Firebird-Tabelle kopieren und dann die Überprüfung starten. Dann kann ich immer noch die Tabelle leeren.

Gruß, Luckner

[Delphi.Narium]

Access kann von Haus aus andere Datenbanken importieren bzw. verknüpfen. Das richtet man sich einmal ein.

Dann kann man auf alle so verfügbaren Tabellen (egal aus welcher DB sie stammen) per SQL (gemeinsam) zugreifen.

Sinnvoll hielte ich es für Deine Situation:

In Access Verknüpfung zur Firebird-Datenbank aufbauen und Konfiguration speichern. In Access 'ne View einrichten, die die von Dir gewünschte Datenprüfung enthält.

Im Programm dann "nur noch" ein select * from View_zur_Pruefung und "fertig ist die Laube".

[himitsu]

Du scheinst ja den Zugriff eher aus dem Firebird heraus zu benötigen.

Aber Firebird scheint da (standardmäßig) nur mit anderen Firebirds reden zu können und mag keine fremden DBMS.
https://firebirdsql.org/rlsnotesh/rn...exctstmnt.html


Die andere Richtung geht wohl (laut Delphi.Narium).

Und LocalSQL wäre wohl auch nichts für dich.

[p80286]

Access ist ein recht schönes Frontend für Datenbanken, wenn man nicht mehr als 64k Datensätze betrachtet. Einmalige oder seltene Aktionen sind dort recht gut aufgehoben.

Gruß
K-H

[Delphi.Narium]

Vor allem auch für den Nichtprofi recht gut zu handhaben.

Und man muss damit ja nichtmal Accessdatenbanken nutzen.

Man kann auf alles an Datenbanken zugreifen, auf das man via ADO / ODBC irgendwie zugreifen kann.

[jobo]

Ich bin kein Freund von Access, aber verschiedene Systeme anzapfen kann es wirklich einfach in MS Manier. Mit einigen Klicks ist die Verknüpfung erledigt, keine Zeile Code nötig.
Noch ein paar Klicks und man hat seine Vergleichsabfrage, wahlweise die positiven oder negativen Fälle ausgegeben.
Noch ein paar Klicks und man hat es vielleicht sogar sinnvoll in einem Makro verpackt, ohne eine einzige Variable zu deklarieren oder sonst irgendwelchen Code zu schreiben.
(und wenn man mag, kann man es auch per COM Server alles programmieren)
- lege eine ODBC Verknüpfung zu meiner Firebird Tabelle xy an (wahlweise vielleicht lieber vorgefilterter view)
- Erzeuge eine Abfrage mit SQL = ...
- Starte die Abfrage und exportiere das Ergebnis oder was auch immer

Programmieren wäre eigentlich erst nötig, wenn es tatsächlich variable Parameter gibt wie wählbarer Datumsbereich, wechselnde Datenquellen oder Ergebnis Export Ziele, fallweise Sonderprüfung bei Fehlern, Plausibilitätsauffälligkeiten, ...

Ich denke ähnlich wie p80286 schrieb, Probleme gibt es erst in speziellen Situationen, die 64k war aber Excel früher mal oder?
M.E. ist die Schwäche (oder besser eine der Schwächen ) von Access nicht die Datenmenge, sondern (ausgeprägter) Mehrbenutzerbetrieb. Es dürfen ruhig ein paar Millionen Records sein, aber bitte nicht alle dran rumfummeln. Vielleicht täusche ich mich auch.

Vielleicht ist es auch eine strategische Sache. Wenn das Ende der Access Anwendung sowieso absehbar ist, macht man die Sache lieber in Firebird.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1398057)

Ich denke ähnlich wie p80286 schrieb, Probleme gibt es erst in speziellen Situationen, die 64k war aber Excel früher mal oder?

Nö, ich hatte ACCESS genutzt um einen monatlichen Bericht zu erstellen. Ist ja klickediklick erledigt. Das Dumme war nur, das ein Dokument nicht da zu finden war wo es hingehörte. Nach zwei Tagen Handarbeit wußten wir, daß ACCESS zwar sortierte aber nur die ersten...K Datensätze. Wenn es wenigstens eine Fehlermeldung gegeben hätte, aber da kam - nichts! Es fehlte auch kein Datensatz. Seitdem halte ich mich an "Vertrauen ist gut, Kontrolle ist besser". Solange es um max 5-10K Datensätze ging, hat ACCESS ordentlich funktioniert, auch Updates! Mehr hab ich mich nicht mehr getraut. Auch weil die Kontrolle so aufwendig gewesen wäre.

Gruß
K-H

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1398062)

Zitat:

Zitat von jobo (Beitrag 1398057)

Ich denke ähnlich wie p80286 schrieb, Probleme gibt es erst in speziellen Situationen, die 64k war aber Excel früher mal oder?

Nö, ..ACCESS zwar sortierte aber nur die ersten...K Datensätze.

* Wenn ich mich richtig erinnere, ist Access etwas eigenartig mit linked Datasources und PKs. Also linked Table mit PK wird gut erkannt und verarbeitet. Linked Table ohne PK muss dann PK angegeben werden, View ebenso. Mir ist nicht klar, warum Access das braucht, aber es wird spätestens dann wackelig, wenn die Datenquelle eben keinen PK hat oder der View den verbirgt bzw. unbrauchbar macht und man mit (max 7?) handverlesenen Ersatzspalten Access einen Pseudo PK angeben muss. Das ist im Zweifel eine schlechte Krücke, weil es natürlich nicht wie ein PK geprüft wird, aber so behandelt, einfach schrottig.
In solchen Zusammenhängen kann ich mir gut vorstellen, dass Abfragen einfach nur die halbe Wahrheit liefern, also im Prinzip unbrauchbar sind.
Ich hatte dann vielleicht Glück, dass auch ohne echten PK immer alles glatt lief.

Feldnamen ohne die doofen eckigen Klammern sind in dem Zusammenhang auch ein Problem, also innerhalb der Access Abfrage.

* Alles ohne Gewähr und ggF. veraltet.

[Luckner]

Das Programm mit der ACCESS-Datenbank wird langsam eingestampft. Deshalb sollte dieser Vergleich schon von der Seite der Firebird-Datenbank sein. Ich denke, dass mit einer Temp-Tabelle in Firebird das einfacher zu machen ist. Es sind nur 3-4 Felder, die ich übertragen muss.

Gruß, Luckner