Clanky ohledne FireDAC?

[pf1957]

Podle mne je to správné chování, a jak jsem již jednou psal, je to schválně

Souhlasim, ale pak je z meho pohledu pic*vina neco takoveho vubec implementovat, protoze musim rict, ze to kolegy notne zaskocilo, protoze na vsech pocitacich, kde se to vyvijelo a testovalo to fungovalo a pri instalaci u zakaznika ne, navic se to chovalo pekne debilne, protoze to naslo nejaky stary ovladac, ktery napr. zprasil casy a datumy do stringu a pak to havarovalo na formatech pri konverzich, o vykonu ani nemluve. A kdyz jsem hledal pricinu, tak toho kolem spravne instalace FireDAC moc pouzitelneho a podorbneho nebylo. A tohle by zrovna stalo za zdokumentovani, protoze jsem to poslal jako namet.

[pf1957]

se FireDAC sice tvari, ze pracuje s vice transakcemi, ale ve skutecnosti dela buhvi co, takze jde napr. commitnout data i v RO txn

Nevim presne o jaky pripad se jedna (vnorene transakce?). Nicmene to by se dit urcite nemelo. Transakce s nastavenym ReadOnly priznakem by urcite nemela mit pravo menit data (uz na strane klienta bych ocekaval vyjimku). Pokud tomu tak je, napisu bug report.

Jen v rychlosti pri veceri :-(
Tohle nevim uplne presne, protoze jsem to na MSSQL nemigroval na Interbase/FB se to nevyskytuje. Nejedna se o nested transakce, ale o Multiple Active Transactions viz napr. http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Managing_Transactions_(FireDAC) dole. A problemy byly zrejme s tim sdilenim vice instanci TFDTransaction, jak o tom pisou v poznamce: Note: You can use more than one TFDTransaction for other database management systems. Then, all TFDTransaction components share the same transaction.

A projevovalo se to v situaci, kdy kolegove pouzili obvykle schema tj. v jednom DB spojeni:
1. jedna trvale zahajena RO transakce
2. na kazdy zapis do DB zahajena extra transakce (s ruznym stupnem izolace, podle toho, co se dela), ktera se explicitne commituje

A jak mi to licili, tak se to chovalo naprosto zhovadile, ze to menilo obsah DB, i kdyz RW transakci commitnuli a instanci uvolnili atd. Myslim, ze na tom nic nevynalezali, proste preklopili fungujici aplikaci pro FB a narazili. Ale skutecne ted nemame cas se tomu venovat. Jen tema, ze tam jsou nejake pitfalls, ktere nuti cloveka vyvarovat se urcitym technikam.

[100308]

[quote  link=topic=16197.msg100296#msg100296 date=1529924131]

se FireDAC sice tvari, ze pracuje s vice transakcemi, ale ve skutecnosti dela buhvi co, takze jde napr. commitnout data i v RO txn

Nevim presne o jaky pripad se jedna (vnorene transakce?). Nicmene to by se dit urcite nemelo. Transakce s nastavenym ReadOnly priznakem by urcite nemela mit pravo menit data (uz na strane klienta bych ocekaval vyjimku). Pokud tomu tak je, napisu bug report.

Jen v rychlosti pri veceri :-(
Tohle nevim uplne presne, protoze jsem to na MSSQL nemigroval na Interbase/FB se to nevyskytuje. Nejedna se o nested transakce, ale o Multiple Active Transactions viz napr. http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Managing_Transactions_(FireDAC) dole. A problemy byly zrejme s tim sdilenim vice instanci TFDTransaction, jak o tom pisou v poznamce: Note: You can use more than one TFDTransaction for other database management systems. Then, all TFDTransaction components share the same transaction.

A projevovalo se to v situaci, kdy kolegove pouzili obvykle schema tj. v jednom DB spojeni:
1. jedna trvale zahajena RO transakce
2. na kazdy zapis do DB zahajena extra transakce (s ruznym stupnem izolace, podle toho, co se dela), ktera se explicitne commituje

A jak mi to licili, tak se to chovalo naprosto zhovadile, ze to menilo obsah DB, i kdyz RW transakci commitnuli a instanci uvolnili atd. Myslim, ze na tom nic nevynalezali, proste preklopili fungujici aplikaci pro FB a narazili. Ale skutecne ted nemame cas se tomu venovat. Jen tema, ze tam jsou nejake pitfalls, ktere nuti cloveka vyvarovat se urcitym technikam.
[/quote]

Tema je to urcite uzitecne (pisu si ). On totiz FireDAC mimo Firebird a InterBase DBMS podporuje jen savepointy uvnitr transakci.

[pf1957]

Monitorovani - 2 dny jsem stravil tim, ze jsem hledal tragicky (vice nez o rad) spatny vykon DB operaci s MSSQL na nekterych (:-O Proc je na nekterych) pocitacich. V aplikaci mame inspekcni okno, ktere pri otevreni nastavi handler OnOutput pro odchytavani a zapne monitorovani. Kolekove monitorovani omylem zapnuli (bez prirazeneho handleru) pri startu aplikace, ze si FireDac berou MonitorBy z "MS" connection stringu apod.

Tomu nerozumim

Tak pro zmenu pri snidani :-(

Jedna se o TFDMonitorCustomClientLink a nekolik veci s nim spojenych:

• obecne by byla zajimava informace, kolik to zere vykonu v zapnutem stavu, protoze ja si desetileti bezne dumpuju do trace logu SQL commandy, jejich parametry pred vykonanim prikazu a vysledek po a na dnesnich pocitacich clovek pri praci s aplikaci nepozna, ze to nekde do souboru pise tuny informaci.
  
• ze to jalove monitoruje (zere vykon), i kdyz nema nastaven OnOutput handler - silene vzroste rezie TFDPhysODBCCommand.CreateDescribeInfos a je zajmave, ze jenom na nekterych pocitacich - proto kolegove nenasli, ze omylem zapnuli ten monitor bez prirazene OnOutput event, zatimco na jinych pocitacich se s tim nedalo vubec delat.
• ConnectionString. Kdyz ten pojem vidim, tak se mi vyjevi strednikem oddeleny seznam parametru, jejichz vyznam jdu hledat k MS a o kterem predpokladam, ze jak ho napisu, tak ho MS pouzije. Ale FireDAC si do nej pridal resp. rozumi v nem proprietarnimu parametru MonitorBy=<typ>, ktery musi byt nastaven, pokud clovek chce monitorovat, jinak zapnuti monitoru v aplikaci nema efekt.
  

Takze si myslim, ze je to cast, o ktere by stalo za to napsat neco ucelenejsiho, nez je tech par prikladu a utrzku v EMBD dokumentaci.

[pf1957]

pracuje "divne" s DateTime tj. pole TSqlTimeStampField s nestandardnimi aditivnimi operacemi abs. cas +/- rel. cas

O tom nevim. Kdyby se nasel cas, mohli bychom se tomu v samostatnem vlakne venovat.

Jeste se vratim k tomuhle problemu ohledne kompatibility FireDAC, akorat se mi to nechtelo preformatovavat z HTML, tak jsem pribalil screen shot nasi isnterni dokumentace.

[miroB]

Iba poznámka k poslednému riadku obrázku, kde sa tvrdí, že komponenty FireDAC nemajú metódu AsDate:
Práve s tým FireDAC "AsDate" pracujem. Ale v SQLite. Takže to bude zrejme závisieť od databázy.

[pf1957]

Iba poznámka k poslednému riadku obrázku, kde sa tvrdí, že komponenty FireDAC nemajú metódu AsDate:
Práve s tým FireDAC "AsDate" pracujem. Ale v SQLite. Takže to bude zrejme závisieť od databázy.

1. ta nase interni dokumentace je 5+ let stara a vztahuje se na migraci z FIB+ na FireDAC v dobe, kdy se FireDAC v Delphi objevily
2. ale ani soucasne komponenty FireDac nemaji TField.AsDate (protoze ho nema Data.DB.TField). FIB+ mely, protoze z duvodu rychlosti nebyly potomkem TDataset takze pole nebyly potomky TField, ale proprietarniho typu TFIBXSQLVAR

[miroB]

Sorry, pravda TField.AsDate neexistuje. Som si neoveril.
Pracujem s týmto

Kód: Delphi [Vybrat]

1. dm.FDQuery1.Params[ j ].AsDate := ..

Pre moje účely a polia typu ftDate stačí.