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

Zitat Zitat von 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