AS/400 Zugriff via Linked Server unter SQL Server 2000

[epsih2]

Hallo!

Wenn ich versuche beim SQL Server 2000 via Linked Server auf die AS/400 zuzugreifen, kann ich auf die AS/400 - Tabellen nur lesend zugreifen, d. h. ich kann kein INSERT, UPDATE oder DELETE durchführen.

Beim Zugriff verwende ich folgende Einstellungen:

ODBC Datenquelle:

* via IBM Client Access V5?1?0 (inkl. aktuelle Services Packs sind installiert)

* Lesen/Schreiben ist erlaubt

* COMMIT-Modus *NONE ist gesetzt

Linked Server:

* über OLE DB Provider für ODBC Driver

AS/400:

Die Tabellen sind nicht journalisiert und sollen es auch nicht werden. Muss ich aber auch angeblich nicht, da ich ja den COMMIT-Modus auf *NONE gesetzt habe.

AS/400 User:

Der AS/400 User, der zum Zugriff via Linked Server benutzt wird, hat selbstverständlich Schreibrechte auf den gewünschten Tabellen.

Hinweis:

* Wenn man die Tabelle journalisiert werden, funktioniert der Schreibzugriff. Die Tabellen sollen aber laut RZ nicht journalisiert werden. Das RZ ist quasi unangreifbar.

* Irgendwer verbreitet das Gerücht, dass der SQL Server die COMMIT-Modus *NONE ignoriert bzw. doch immer versucht eine Transaktion zu starten. Deswegen auch der bekannt SQL7008-Fehler. Stimmt das? Wenn ja, wie kann man es umgehen?

* funktioniert es generell nicht beim Linked Server als Provider den IBM AS400 Client Access Treiber zu verwenden -ich verwende deswegen den OLE DB Provider für ODBC Driver-, oder stelle ich mich nur zu ungeschickt an?

Ich hoffe, Ihr könnt mir helfen?

Gruß

epsih

P.S.

Geht nicht zu streng mit mir ins Gericht, wenn Bezeichnungen nicht 100%ig stimmen, ich schreibe gerade von zu Hause aus, meint ich habe das System nicht vor mir und alle Begriffe schreibe ich aus dem Gedächnis und das funktioniert nicht immer ganz korrekt ...

[Fuerchau]

Es liegt tatsächlich am SQL-Server. Dieser versucht IMMER eine Transaktion zu starten, egal welchen Treiber man verwendet.
Will man schreibend zugreifen, empfielt sich eine separate Verbindung oder die Tabellen (wie bereits probiert) zu journalisieren.

[BenderD]

Hallo,

ergänzend sei vielleicht noch gesagt, dass es heutzutage keinerlei stichhaltige Argumente gegen Journalisierung mehr gibt, das blanke Gegenteil ist der Fall, Journalisierung empfiehlt sich in den meisten Fällen selbst dann, wenn man keine Transaktions Sicherung mit Commit verwendet!

Dieter Bender

Es liegt tatsächlich am SQL-Server. Dieser versucht IMMER eine Transaktion zu starten, egal welchen Treiber man verwendet.
Will man schreibend zugreifen, empfielt sich eine separate Verbindung oder die Tabellen (wie bereits probiert) zu journalisieren.

[Fuerchau]

@Dieter

Versuch das mal mit dem BrainXPPS-ERP. Innerhalb einer Stunde Aufzeichnung einer einzigen Datei (Stammdatei) entstanden ca. 1 GB Journal bei ca. 150 Usern.
Ich kann mir durchaus vorstellen, dass andere ERP-Systeme mit durchaus ähnlichen Datenvolumen umgehen.
Der Grund ist hierbei, dass 90% aller Zugriffe eigentlich Pseudo-Updates sind. Sperren werden über ein Datenfeld gelöst, so dass auch tatsächlich unterschiedliche Images bei einem Update entstehen (die Option tatsächliche Unterschiede aufzuzeichnen zieht also nicht wirklich).
Der Vorgang ist also:
1. Read mit Lock
2. Setze Sperrfeld
3. Update
4. Read mit Lock
5. Änderung tatsächlicher Felder
6. Update
7. Read mit Lock
8. Lösche Sperrvermerk
9. Update

[BenderD]

@Baldur: gerade hierbei wäre Transaktionssicherung dringendst angeraten (dauerhaft gesperrte Sätze drohen!!!)
Schädlich wäre es keinesfalls, bei entsprechender Vorgehensweise:
Journalgröße limitieren und alles auf automatisches Handling einstellen inklusive löschen; Eigener ASP für Journale und Receiver, je nach Plattenkonstellation. Das Journalisieren verhindert dann das forcierte rausschreiben der Blindupdates und das Journal wird rein sequentiell geschrieben. Davon abgesehen ist Journalisierung Dateieigenschaft und kann auch selektiv eingesetzt werden (solange nicht Commit Steuerung anderes erfordert).
Nebenbei bemerkt: ich bewundere immer wieder die Risikofreude einiger Softwarehäuser, ich würde jedem Kunden, dem ein wirtschaftlicher Schaden durch krumme Lagerbuchungen, dauerhaft gesperrte Sätze, oder ähnliches ensteht, unter Berufung auf das europäische Produkt-Haftungsrecht auf Schadenerstaz zu klagen, wenn Software keine Transaktionssicherheit durch Commit sicherstellt und damit nicht dem Stand der Technik entspricht.
Meine Empfehlung bleibt: alles journalisieren außer temporären Dateien.

@Dieter

Versuch das mal mit dem BrainXPPS-ERP. Innerhalb einer Stunde Aufzeichnung einer einzigen Datei (Stammdatei) entstanden ca. 1 GB Journal bei ca. 150 Usern.
Ich kann mir durchaus vorstellen, dass andere ERP-Systeme mit durchaus ähnlichen Datenvolumen umgehen.
Der Grund ist hierbei, dass 90% aller Zugriffe eigentlich Pseudo-Updates sind. Sperren werden über ein Datenfeld gelöst, so dass auch tatsächlich unterschiedliche Images bei einem Update entstehen (die Option tatsächliche Unterschiede aufzuzeichnen zieht also nicht wirklich).
Der Vorgang ist also:
1. Read mit Lock
2. Setze Sperrfeld
3. Update
4. Read mit Lock
5. Änderung tatsächlicher Felder
6. Update
7. Read mit Lock
8. Lösche Sperrvermerk
9. Update