AS/400 Zugriff via Linked Server unter SQL Server 2000

[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