Microsoft Access als Frontend für db2?

[Fuerchau]

Dies sind Programme, die ohne jeglichen Bedienereingriff arbeiten (auch Hintergrundprogramme).

[RobertPic]

@Robert

Das ist so nicht ganz richtig.
Für Access als Frontend zur AS/400 gilt das gleiche, wie mit einem SQLRPG/LE-Programm...

?????
Eindeutiges Veto:
Bei Access ist wesentlich mehr zu beachten, als bei Zugriffen auf der AS/400. Access puffert bei verknüpften Abfragen und/oder irgenwelchen Where-Conditions schon mal die ganzen Dateien am PC zwischen. Genauso schlecht ist die Verwaltung von grossen Recordssets.

Bei uns gilt die Faustregel(n): nur kleine Dateien dürfen über den Zugriff der verknüpften Dateien verarbeitet werden, alles andere läuft über ODBC-Connections und da noch am besten mit Stored Procedures.

Wer einmal einen ODBC-Trace von Access angeschaut hat, kann nicht mehr behaupten, dass Access ein guter Client ist.

Damit stehe ich auch nicht allein da:

http://www.sql-server-performance.com/access.asp

Kleiner Ausschnitt gefällig:
If you are really interested in the fastest performance, don't use Access as a front-end to a SQL Server database.

@juergenkemeter:
Wie gross sind die zugriffenen Dateien ungefähr? Wie viele andere M$-Produkte funktioniert auch Access bei kleineren Mengen 1a. Aber eine Applikation für über 200 User und 2 GB Daten war/ist mit verknüpften Dateien und programmieren wie für einen PC definitv nicht machbar. Hier brauchte es Handarbeit.





LG Rob

[Fuerchau]

Wie schon gesagt, das Design ist wichtig.
Wenn ich lokale Tabellen mit verknüpften Tabellen verarbeite, hast du wohl recht.

Was hindert mich denn daran, die Abfragen als Passthru-SQL's zu stricken ?
Das funktioniert auch mit Parametern, zwar nicht mehr mit Namen (automatisch aus Formularen/Berichten) aber durchaus performant.

Es funktioniert sogar gut, wenn ich verknüpfte Tabellen verbinde, wenn sie die gleiche Verbindung haben (DSN). Ich muss allerdings sehr gut aufpassen, bei der Verwendung der Verknüpfung.

Klar ist auch, wenn ich die RecordCount-Eigenschaft verwende (z.B. Fortschrittsanzeigen), dass dann die ganze Abfrage gepuffert wird.

Auch dabei kann ich mir mit SQL-Passthru sehr gut behelfen. RecordCount ist zwar dann immer -1, aber folgende Abfrage funktioniert ab V5R1 auch ganz gut:

with
xQRY as (select .... where ... group ...)
select xqry.*, count(*) from xQry
order by ....

Damit habe ich die Anzahl der Sätze als letztes Feld des Recordsets.

Ich habe bereits mehrere Access-Frondends zu DB2/400 und MSSQL-Server (auch gemischt in einer Anwendung) erstellt.
Der klare Vorteil ist die einfache Formular-/Berichtsgestaltung.
Die Nachteile mache ich halt mit Programmierung und Design wieder mehr als wett.

Das einzige, was mich stört(e), dass die MDB ständig wächst, selbst wenn man ausschließlich verknüpfte Tabellen verwendet.
Bei Access2003 kann ich allerdings die MDB beim Verlassen automatisch wieder komprimieren.

[RobertPic]

...
Was hindert mich denn daran, die Abfragen als Passthru-SQL's zu stricken ?
Das funktioniert auch mit Parametern, zwar nicht mehr mit Namen (automatisch aus Formularen/Berichten) aber durchaus performant.

Nichts anderes wollte ich damit sagen. Wenn man Performance braucht, muss man etwas "tiefer" gehen.

Auch ich kann Access eigentlich für die Software-Entwicklung (mit obengenannten Empfehlungen) von AS/400-Client-Anwendungen empfehlen. Access ist sicher eine Entwicklungsumgebung, welche gut zur AS/400-Klientel passt - ganz im Gegensatz zu Java.

In Verbindung mit Stored SQL-Procedures (welche RPG oder Cobol aufrufen) ist es auch eine Möglichkeit ein schöne Benutzeroberfälche in Access zu entwickeln und Teile der alten 3GL-Programme weiter zu benutzen.

Und im Vergleich zu AS/400-spezifischen Tools wie z.B. LANSA ist es auch recht günstig in der Anschaffung.

LG Rob