Kde jsou data ?

[Delfin]

Tak jeste jinak. Pokud jsi transakci explicitne nenastartoval pomoci StartTransaction a mas zapnuty AutoCommit, pak je Ti Commit a Rollback k nicemu. Bude to FireDAC ktery bude pro kazde volani ExecSQL ridit transakce a to pro kazde volani jednu. No a v kodu ktery jsi ukazal zadne volani StartTransaction neni. Jsou jen dve moznosti. Bud transakce ridis Ty nebo FireDAC. Osobne v tomto vlakne nevidim problem a tudiz nemuzu poradit.

Pokud mas AutoCommit zapnuty a pouzijes:

Kód: Delphi [Vybrat]

1. FDQuery1.ExecSQL('...');

Pak se FireDAC o vse postara za Tebe. Pokud mas volani vic a chces je spustit bud vsechny nebo zadny, pak pouzijes napr.:

Kód: Delphi [Vybrat]

1. FDQuery1.Transaction.StartTransaction;
2. try
3.   FDQuery1.ExecSQL('...');
4.   FDQuery1.ExecSQL('...');
5.   FDQuery1.ExecSQL('...');
6.   ...
7.   FDQuery1.Transaction.Commit;
8. except
9.   FDQuery1.Transaction.Rollback;
10.   raise;
11. end;

[Delfin]

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.

To ano, ale v prezentovanem kodu (ktery je mazanim, nechapu proc) je jen jedno takove volani 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.

[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.

[Delfin]

Jen pridam, ze pokud bys chtel real time refresh, mohl by ses podivat na TFDEventAlerter.

[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.

[Delfin]

a ja hypotezu s izolovanymi transakcemi napsal jeste pred tim, nez poslal ukazku kodu

Vim, vim. Hodnotil jsem Pro me dotazy z tohoto vlakna nedavaji moc smyslu.

[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.

[Delfin]

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.

Ta kolekce parametru se tvori (s defaultnim nastavenim) prave pri nastaveni SQL prikazu. Ale ani tak na tom nezalezi. Ve finale se FireDAC pokusi o implicitni konverzi hodnot parametru, a pokud je mozna konverze, nastane (a je jedno zda jsou parametry vytvoreny v design time nebo real time).

Cely proces zpracovani parametru ve FireDAC muzu popsat, kdyby mel nekdo zajem (byt uz k tomu mozna nekdy doslo). Staci rict