[50594] in SAPr3-news
Re: harte Updates - no problems?
daemon@ATHENA.MIT.EDU (Jürgen Bauer)
Mon Jul 12 10:33:43 2004
To: sapr3-news@mit.edu
Date: Mon, 12 Jul 2004 16:32:45 +0200
From: "Jürgen Bauer" <bauer_j@web.de>
Message-ID: <40f2a10d$0$6744$9b4e6d93@newsread2.arcor-online.net>
Hallo Roland
> Hallo NG,
> wie steht Ihr zu harten Updates?
Ich persönlich halte davon überhaupt nichts.
1. Die Tabelle die upgedatet wird könnte durch durch andere Programme/User
im Zugrif sein.
-> Das programm arbeitet mit veraltetet Daten
2. Stimmt der Select überhaupt? Ein Kollege von mit hatte mal die TRDIR
geupdatet.
Allerdings hatte er einen kleinen Fehler inb der Where-Bedingung -> Ende
vom Lied war
das die Datensicherung erneut eingespielt werden musste....
3. Hat die Feldänderung vieleicht Einflüsse auf andere Bereiche?
In deinen fall setzt du ja die Projektnummer im Arbeitsplan des
Fertigungauftrags
Wird diese bei euch im CO ausgewertet? Nicht das ihr da
auseinanderlauft.
Aber es gibt manchmal notwendigkeiten dies zu tun, da dies der einzige Weg
ist.
Dann sollte man allerdings folgenden Weg einschlagen:
A) Live mit Usern am System
1. Versuchen die Tabelle die gelesen wird, und die die geschrieben wird mit
den
Standard-Sperrobjekten die die jeweiligen Transaktionen die auf die Tabellen
zugreifen,
zu sperren, bzw. die übergeornetetn Sperrobjekt verwenden.
2. Erst dann den Update absetzen
3. Falls es für die Tabelle ein Änderungsprotokoll gibt, dieses ebenfalls
füllen,
sonst kann keiner hinterher feststellen was wann und warum geändert wurde.
-> Sonst bekommt der kleine Sachbearbeiter, der vieleicht in deine Fall den
Fertigungsauftrag angelegt hat eine auf den Deckel, obwohl er das gar nicht
verbrochen
hat.
4. Commit und Freigabe der Sperre absetzen.
B) Ohne User. mit !ausgeschalteter! Batchverarbeitung hier kann evtl. Punkt
1 entfallen
mfg
Jürgen Bauer
