• být naprosto korektní
• ukazovat na chybné ošetření zápisu do sdíleného souboru z procedury
• ukazovat na potřebu promyslet analytické dopady některých programových řešení.

Uvedený postup datového editoru vlastně zabraňuje DEADLOCKu v určité situaci (někdo změnil větu kterou edituji), kterou vlastně nelze řešit jinak (pokud již nastala). Lze ale rozebrat důvody, proč vlastně může nastat a případně výskyt těchto důvodů omezit na minimum.

Podrobnější popis

• Pesimistická strategie
  Při provedení změn do věty souboru se (pesimisticky) předpokládá, že se i jiná stanice pokusí v průběhu editace do věty provést svoje změny. Aby se tomu zabránilo, uzamkne první stanice větu po celou dobu editace. Druhá stanice nemůže větu začít editovat. Takže změny ve větě provede ta stanice, která začně dříve s editací.
  
• Optimistická strategie
  Při provedení změn do věty souboru se (optimisticky) předpokládá, že během editace se jiná stanice nepokusí o totéž (provést změny ve stejné větě). Pokud se tak přece jen stane, uplatní své změny ta stanice, která ukončí editaci (provede zápis změn) jako první. Takže změny ve větě provede ta stanice, která editací dříve ukončí.
  

V PC FANDu je jedna situace, kdy dojde k tomu, že datový editor nerespektuje zámek na větě a propíše změny i do uzamčené věty. Je to v případě, že při potvrzení změn ve větě (ukončení editace věty) se mají provést aditivní změny do nadřízených souborů. Tyto změny se postupně kaskádovitě provádějí (úrovní nadřízenosti může být více) a při tom se narazí v nějakém nadřízeném souboru na uzamčenou větu. V tomto případě se změny propíšou i přes zámek. Jiné možné řešení by bylo stornování (ROLLBACK) všech dosud provedených změn. Kromě toho, že FAND ROLLBACK (transakce) nepodporuje by toto řešení mělo i jiné analytické dopady.

No a pokud ona uzamčená věta nadřízeného souboru byla právě editována z jiné stanice, provede před propsáním svých změn výše uvedenou kontrolu. Zjistí aditivní změnu a nahlásí onu hlášku, o kterou se jedná.

Je na místě připomenout, že blokování a zamykání datového editoru nelze přímo ovlivnit (ani to nemá smysl). Takže při konkurenční práci datových editorů řeší uvedený postup při provádění aditivních změn vlastně situaci typu DEADLOCK. Jde o aplikaci optimistické strategie sdílení vět.

Ovšem, podobné situace mohou nastat při změnách, které se provádí z procedur. Např. změna z procedury do věty, kterou jiná stanice edituje. Zde se uplatní příkaz WITH LOCKED.

Dvě důležité upozornění na závěr

1. Aby nedošlo k omylu je nutno zdůraznit, že v uvedených situacích lze sice prolomit zámek na větě, ale nikdy nelze prolomit mod blokování (WITH SHARED). Ono prolomení zámku také vlastně vypadá tak, že v situaci, kdy mody blokování souboru umožňují více stanicím zápis do souboru (všechny stanice mají nejvýše mod NoCr) jedna ze stanic se na případné uzamčení věty prostě nezeptá.
    
2. Pro jednoduchost se zatím hovořilo o jiné stanici, která přepíše rozeditovanou větu. Je nutno upřesnit, že původní stav věty může přepsat i ta samá stanice - ta samá aplikace - např. v exit-proceduře v rámci aktuální editace. Z hlediska datového editoru je přímý přístup (zápis soubor[edrecno].udaj:= ) z exit-procedury do editované věty považován za nekorektní. Korektně se s editovanou větou pracuje přes parametr record of editovaný soubor.

Příkaz WITH LOCKED sám o sobě nezabrání ostatním stanicím v přístupu k uzamčené větě. Zabrání v přístupu jen těm, které se na zámek zeptají = také zkusí WITH LOCKED.