[50618] in SAPr3-news
Re: harte Updates - no problems?
daemon@ATHENA.MIT.EDU (M. Reibnitz)
Tue Jul 13 12:50:05 2004
To: sapr3-news@mit.edu
Date: 13 Jul 2004 09:50:00 -0700
From: mreibnitz@web.de (M. Reibnitz)
Message-ID: <d8223ee1.0407130850.5da088f2@posting.google.com>
"Andreas Post" <andreas.postNIXSPAM@pan-it.com> wrote in message news:<ccuob5$e1$1@ngspool-d02.news.aol.com>...
> "Jürgen Bauer" <bauer_j@web.de> schrieb im Newsbeitrag
> news: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.
>
> Der Befehl UPDATE sperrt Datensätze.
>
> Beispiel:
>
> UPDATE LAGP SET SKZUE = 'X'
> WHERE LGNUM = '001'
> and LGTYP = '001'
> and LGPLA = '01-01-01'.
>
> Laut R/3 Hilfe wird dann der Datensatz geperrt.
Es wird aber nur eine DB-Sperre gesetzt, gemeint war wohl eher das
SAP-Sperrkonzept. D.h. eine Anwendung könnte Daten logisch sperren,
und ein paralleler DB-Update macht dann alles putt, da keine
"physische" Sperre auf DB-Ebene sitzt.
> Davon abgesehen, ein Feld in einer Tabelle zu ändern ist immer gefährlich.
Nein, nicht immer.
> Es gibt freilich Tabellen und Felder, bei denen das gefahrlos gemacht werden
> kann. Aber, kaum ein Mensch kennt die Zusammenhänge und Abhängigkeiten von
> Feldinhalten in irgendwelchen Tabellen. Ein UPDATE auf eine Tabelle kann
> somit technich einwandfrei funktionieren, doch der Schaden der damit
> angerichtet werden kann, ist gigantisch. Oftmals merkt man das erst Monate
> später.
Da hast Du recht.
> Daher sollte man immer Standartmittel (Funktionsbausteine, BAPIs und zur Not
> sogar noch den BatchInput) nutzen, um Feldinhalte zu verändern.
Aber die stehen nicht immer zur Verfügung, dann ist ein harter Update
unumgänglich. Und wenn man wirklich weiß was man tut, und die bereits
genannten Rahmenbedingungen beachtet, sollte ein harter Update
unproblematisch sein.
Gruß, Mark