Tabellenfelder 2 versch. Datenbanken vergleichen

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

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

Zitat von jobo:

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