Microsoft Access als Frontend für db2?

[juergenkemeter]

Hallo,
ist es möglich, in Access Formulare, Abfragen u.ä. zu erstellen, die dann auf eine SQL - Datenbank in db2 von IBM zugreifen?

VG,
Jürgen

[Fuerchau]

Aber klar.
Dazu gibt es genügend Beispiele im Forum, aber:

Über "Tabelle->Verknüpfen->ODBC" richtest du eine ODBC-Quelle mit dem CA-Treiber ein und kannst dann auf alle Tabellen zugreifen.

Es gibt allerdings ein paar Einschränkungen:
PF mit maximal 31 LF's, ansonsten verknüpfe mit der LF !
Max. 255 Felder in einer Tabelle !

Access möchte zusätzlich die Definition eines UNIQUE-Schlüssels. Normalerweise ermittelt er ihn selber, aber wenn er das nicht kann wird eine Feldliste angeboten.
In diesem Fall lege lieber einen UNIQUE-Schlüssel auf die DB, da Access damit sonst nicht zurechtkommt.

Default ist im ODBC-Treiber Commit auf *CHG gesetzt. Wenn deine DB aber nicht journalisiert ist, setzte Commit auf *NONE (Register Server->Erweitert).

Probleme bereiten ggf. Abfragen auf Abfragen (Performance) und Verknüpfungen mit lokalen Tabellen.
In solchen Fällen lohnen sich dann SQLPASSTHRU-Abfragen.

Ansonsten gehts ohne weitere Probleme.

[juergenkemeter]

Hallo Fuerchau,
danke für deine Tipps!
Da ich leider noch kein AS/400-bzw. Access-Profi bin, habe ich Fragen zu deinem Beitrag:

- wo genau richte ich in Access den ODBC-Treiber ein (Access97)?
- Was heissen die Abkürzungen CA-Treiber, PF, LF
- Muss ich in DB2 einen "UNIQUE Schluessel" definieren oder in DB2;
wie mache ich das?
- was meinst du damit, dass Verknüpfungen auf lokale Tabellen
Probleme bereiten? Die DB2-Tabellen sind doch auf einem Server.


Hoffe dich nicht mit meinen Anfängerfragen zu nerven

Jürgen

[Fuerchau]

Welche Access-Vesion ist letztlich egal.
Suche mal hier im Forum nach ACCESS und ODBC. Da sind verschiedene Beispiele erklärt.

CA=ClientAccess (jetzt auch iSeriesAccess)
PF=Physical File
LF=Logical File

Diese Begriffe spielen mit der DB2/400 eine Rolle.

Bei DB2 gibts allerdings noch verschiedene Varianten. Für Zugriffe auf andere Host's benötigst du DB2/Connect.
Dann gibts noch DB2-Private (ganz umsonst) mit eigenen Triebern und Zugriffen.
usw.
usw.
usw.
:

Dies würde das Forum hier sprengen.

Hier gehts ausschließlich um AS/400->iSeries->i5

[juergenkemeter]

Hallo,
ist dann Access mit DB2 im Hintergrund netzwerkfähig?
Muss auf jedem Klienten-PC Access und der ODBC-Treiber installiert sein?

VG,
Jürgen

[Fuerchau]

Jeder PC, der Daten per ODBC abruft, benötigt einen ODBC-Treiber. Access ist nicht so intelligent, dass, wenn der Backend auf einem Server liegt, verknüpfte Tabellen über den Server abgefragt werden.
Access wird ja schließlich auch auf jedem PC benötigt. Wenn Access nicht selber vorhanden ist, benötigt man mindestens die Access-Runtime auf jedem PC.

Anders siehts da schon mit echten DB's aus (SQL-Server, Oracel, usw.). Dies sind ja Server und manche davon unterstützen auch ODBC-Tabellen, so dass diese auf dem Server verknüpft und auch abgerufen werden.

[RobertPic]

@juergenkemeter

Ich wäre allerdings vorsichtig Access mit verknüpften DB2-Dateien auf viele Benutzer bzw. große Daten loszulassen.

Access arbeitet im Normalfall nicht besonders effektiv mit fremden Datenbanken. Aber solange die Datenmengen nicht so groß sind, sollte das nicht dramatisch auffallen.

Z.b. Reports für kleinere Dateien sollten kein Problem darstellen.

Für grössere Aufgaben darf man die Datei nicht verknüpfen, sondern muss mit SQL-Anweisungen, am besten SQL-Procudures arbeiten.

LG Rob

[Fuerchau]

@Robert

Das ist so nicht ganz richtig.
Für Access als Frontend zur AS/400 gilt das gleiche, wie mit einem SQLRPG/LE-Programm. Sind genügend Zugriffspfade vorhanden, ist das genauso performant wie native auf der AS/400.
Bei Dialog-Anwendungen ist noch der Vorteil, dass die Batch-CPW in Anspruch genommen wird.
Es kommt mitunter sogar zu Entlastungen der AS/400, da ja die reine Rechenlogik in das Frontend verlagert wird und sich die AS nur noch um DB-Zugriffe kümmern muss.

Sicherlich sollte man keine Batchanwendungen in Access realisieren wenn große Datenmengen verändert werden.
Reine Reports lassen sich mit Access durchaus eleganter lösen.

Also wie immer:
Es kommt auf das Anwendungsdesign an um performante Lösungen zu bekommen !

[juergenkemeter]

Hallo,
was versteht man unter "Batch-Anwendungen"?

mfg
Jürgen

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