Insert, Edit - prístupnosť údajov v tabuľke

[Stanislav Hruška]

Databáza FB.Potrebujem pre vykonaním Post overiť, či cudzí kľúč už je použitý v tabuľke. Unique to v mojom prípade nerieši.
Viem, že po použití Post, bez commit už mám novo zadané údaje v tabuľke.
Ale neviem, či tam sú k dispozícii ešte pre Post.
Myslím tým to, že ak spustím Query, či načíta aj nové/zadávané údaje, alebo len pôvodné. Existujúce pred Insert či Edit.
Prešiel som na DB komponenty a tak musím riešiť to, čo som predtým nepoznal 

[Jirka]

Databáza FB.Potrebujem pre vykonaním Post overiť, či cudzí kľúč už je použitý v tabuľke. Unique to v mojom prípade nerieši.

Komponenta datasetu by měla mít událost OnBeforePost

Prešiel som na DB komponenty a tak musím riešiť to, čo som predtým nepoznal 

A proč jsi tedy přecházel? 

[vandrovnik]

IBX komponenty to mají tak, že samotné Edit a Insert v databázi ještě nic neudělají - změny zapíše teprve Post. Firedac to asi bude mít stejně.

Není lepší testovat, zda Post prošel bez problémů, než to ověřovat předem? Pokud k databázi přistupuje více uživatelů, tak mezi ověřením a Post stejně může někdo jiný údaje změnit.

[Stanislav Hruška]

A proč jsi tedy přecházel? 

Lebo to sú TMS a riešia za mňa veľa vecí. Napríklad obmedzenia. Dosť som nad tým rozmýšľal a rozhodol som sa, že to stojí zato. Ešte sa mi nestalo, aby som mal nejaké problémy. To sa žiaľ o štandardných DB komponentoch povedať nedá. Preto som ich pôvodne opustil. Ako ďalší bonus mám aj zjednodušenia v kóde. Mínusom je ošetrovanie vecí, ktoré som mal urobené centrálne a teraz to padlo + iný prídavný kód, ktorý predtým nemusel byť. Ale to sú len také jednoduché veci. Napr. ak mením údaj, tak to musím zapísať priamo do tabuľky. Nestačí to zapísať len do komponentu (tak ako predtým).

Není lepší testovat, zda Post prošel bez problémů, než to ověřovat předem?

To sa práve nedá. V skutočnosti sa tie údaje môžu opakovať. Ale pre jedno SVB v jednom roku to môže byť len raz. Preto ručná kontrola.

Pokud k databázi přistupuje více uživatelů, tak mezi ověřením a Post stejně může někdo jiný údaje změnit.

Na ten test som myslel. Len som dúfal, že mi tu niekto dá odpoveď. Ale ten "asi jeden" už odtiaľ odišiel   To budem riešiť tým, že s jedným SVB bude môcť pracovať len jediný pracovník. Ak sa k sieťovej verzii vôbec dostanem.

[vandrovnik]

To sa práve nedá. V skutočnosti sa tie údaje môžu opakovať. Ale pre jedno SVB v jednom roku to môže byť len raz. Preto ručná kontrola.

Tak pokud nechceš použít unique index složený z více polí (svj, rok, pole), tak doporučuji vytvořit v databázi trigger before insert or update a kontrolu udělat v něm; narazí-li kontrola na problém, pomocí Exception vyvolá výjimku, takže zápis záznamu neproběhne. Výjimka se musí nejdří definovat pomocí Create Exception.

Osobně jsem unique indexy přestal používat, protože se mi s nimi hůř pracovalo při synchronizaci dat mezi pobočkami.

[Stanislav Hruška]

Tak pokud nechceš použít unique index složený z více polí (svj, rok, pole),

To mi ani neprišlo na um. Ja si radšej všetko ošetrím, než by som mal pracovať s výnimkou. Aj tak ich neovládam   Výnimky mám zo svojho pohľadu len ako poslednú ochranu pred zápisom nesprávnych údajov. Zistím zlý údaj, vypíšem oznam a vrátim užívateľa na konkrétny komponent. Je to jednoduché, len občas niečo vyskočí ako tento problém, a DB a užívateľa ničím zbytočným nezaťažujem.
Mám v DB použité aj unique ako poistku. Ale ja si vždy najprv údaje overím.

[Stanislav Hruška]

Osobně jsem unique indexy přestal používat

Ako to riešiš teraz?
Rozmýšľam nad tou výnimkou, lebo riešenie sa javí podstatne zložitejšie než som si myslel. Hlavne to komplikuje Edit kontra Insert.
Ja nemusím riešiť konkurenčný prístup k DB.

[vandrovnik]

Osobně jsem unique indexy přestal používat

Ako to riešiš teraz?
Rozmýšľam nad tou výnimkou, lebo riešenie sa javí podstatne zložitejšie než som si myslel.
Ja nemusím riešiť konkurenčný prístup k DB.

Používám triggery BEFORE INSERT OR UPDATE.
Kontrolu v nich provádím, jen pokud se role uživatele liší od role vyhrazené pro import dat z ostatních poboček.