Kde jsou data ?

[pf1957]

Pokud spoustis jeden prikaz jako je i tento priklad, neni duvod autocommit nepouzit.

Je, protoze pak vznikaji paskvily, ktere v 95 % funguji, jak pise OP. Osobne bych rezim AutoCommit zcela zrusil: slusne napsany soft bude pouzivat vsude jeden zpusob rizeni transakce a protoze AutoCommit je pro ten ucel k nicemu, je jasne, jak to delat ;-)

A FireDAC je inteligentni natolik, ze pokud explicitne nastartujes transakci, implicitni nevytvori (takze tim zavolanim StartTransaction

Vetsina DB connectivit pri explicitnim nastartovani transakce lokalne shodi  AutoCommit, ale je lepsi pri kazdem vytvoreni instance transakce ho explicitne priradit na False (treba pomoci interposed tridy, ktera to v konstruktoru shodi jednou pro celou aplikaci), protoze tim davam jasne najevo vsem ctenarum kodu, ze vim co delam a transakce si budu vsude ridit sam.

P.S. chybi Ti tam Rollback.

Nejen, Ma-li byt rizeni transakce ciste, musi byt StartTransaction pred try, protoze kdyz se nepovede zahajit transakci, tak to nesmi spadnout na Rollback, ale tu chybu je treba odchytit v jinem (vnejsim) scope try-except.

[pf1957]

Nevznikaji, protoze FireDAC za Tebe pouzije implicitni transakci. Je to uplne to same co bys udelal explicitne v kodu.

To plati jen pro jeden izolovany ExecSQL. Ale lidi jako OP, kteri nikdy neslyseli o Commit, nenapadne, ze kdyz si pridaji jeste dalsi ExeSQL, ze kazdy pobezi v jine transakci a ze to nebude ACID.

[rustymattock]

Tak vám všem děkuji.
Doplním tam dle doporučení Commit i Rollback. Snad to opravdu bylo ono.

P.S: k čemu je Rollback(když už čtu, že tam musí být) ?
...a ExecSQL je v kódu opravdu víc (7 nebo

[pf1957]

P.S: k čemu je Rollback(když už čtu, že tam musí být) ?

Google negoogluje? Heslovite treba http://nb.vse.cz/~palovska/bivs/DBII_2_advancedSQL.pdf

[pf1957]

Snad to opravdu bylo ono.

Tezko rict, ale obecne plati, ze s transakcemi a thready je treba pracovat cistym zpusobem, protoze jinak mohou vznikat tezko laditelne/simulovatelne/lokalizovatelne chyby a je treba udelat maximum pro to, aby tato kategorie chyb pokud mozno vubec nevznikla. Samozrejme to zacina u teorie...

[rustymattock]

No já vůbec původně s databázou nepočítal. Až při testování se usoudilo, že bude "cool", když bude data sdílet všech 9 linek.
Takže ANO, pustil jsem se do databázy, o které skoro nic nevím, představoval jsem si to jako Hurvínek válku a teď za to trpím :-(

Delfin:
Přes celou aplikaci je asi 7-8 dotazů na databázu. Jak CELECT, tak INSERT, UPDATE i DELETE. V různém pořadí, jak uživatel právě potřebuje.
Vyzkouším co jste napsali, prostuduji odkaz, který mi kolega výše zasla a budu věřit, že mě to posune.

[pf1957]

To ano, ale v prezentovanem kodu (ktery je mazanim, nechapu proc) je jen jedno takove volani

Ve slovnim popisu ma "...Do tabulky vložím několik záznamů..." a ja hypotezu s izolovanymi transakcemi napsal jeste pred tim, nez poslal ukazku kodu

A popis taky nedava smysl. Pokud OP prida vice zaznamu s autocommit ExecSQL, pak se do DBMS vlozi zadny, vsechny nebo jen nektere. Kdyz pak zaznam smaze, objevi se jeden z pridanych. To zkratka nedava smysl.

Nicmene neviditelnost dat je typickym projevem operaci spoustenych ve vzajemne izolovanych transakci, ale pravdou je, ze pokud by pracoval v rezimu AutoCommit, tak by k tomu nemelo dojit, protoze vsechna data by mela byt commitnuta a read transakce by na ne mela videt. Ovsem vete "...Když dám pak SELECT * FROM... " rozumim tak, ze v nejakem toolu napr. v MS Management studiu zadam query a ono se to chova tak, jak je popsano.

[Radek Červinka]

..
  DataModule1.FDQuery.SQL.Clear;
  DataModule1.FDQuery.SQL.Text:='DELETE FROM box_comp WHERE A2C=:A2C AND Line=:Line AND Count=:Count AND MyStamp=:TimeStamp';
  DataModule1.FDQuery.ParamByName('A2C').AsString:=BoxComp[ARow].A2C;
  DataModule1.FDQuery.ParamByName('Line').AsString:=CompList.MyLine;
  DataModule1.FDQuery.ParamByName('Count').AsInteger:=BoxComp[ARow].Count;
  DataModule1.FDQuery.ParamByName('TimeStamp').AsFloat:=BoxComp[ARow].MyStamp;
..

Chyba moze byt v tom, ze  DataModule1.FDQuery.Params.. nemaju urceny vopred typ parametrov.
Query nie je "Prepared" a v podstate neprijma ziadne hodnoty, aj ked sa zda, ze ano..

Klikni si v "Object Inspector" na "DataModule1.FDQuery"
a tam
Params (TFDParams)
Rozbal tie 4 parametre a pridaj im hodnoty DataType resp FDDataType

To je špatná rada, jednak mění SQL, tedy FireDac automaticky vytvoří sadu parametrů a za druhé se spoléhat na nastavení parametrů z design modu je dlouhodobě cesta do záhuby. Teď jsem to řešil u jednoho velkého cizího projektu, kdy v design modu byly nastaveny parametry, které se datově shodovaly (resp. v okamžiku vzniku i názvově), ale jejich jména se časem (>10 let) rozešla se jmény v DB.

Takže v kodu pořád fungovalo ParamByName, protože to našlo parametr z design modu a typově pořád odpovídal parametru na pozici v DB, ale jakmile se něco provedlo se storedProc (resp. se zavedl validace parametrů během migrace na FireDac z in-house komponent z doby D5) tak se to hodně rozsypalo.

Vzhledem k tomu, že FireDac cachuje parametry bych se nebál vykašlat se na parametry z design modu.

P.S.: já pokud mohu, tak se komponentám v datamodulu snažím vyhnout.