Autor Téma: Clanky ohledne FireDAC?  (Přečteno 3639 krát)

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 2444
  • Karma: 131
    • Verze Delphi: D2007, XE3, DX10
Re:Clanky ohledne FireDAC?
« Odpověď #15 kdy: 25-06-2018, 20:14:22 »
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.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 2444
  • Karma: 131
    • Verze Delphi: D2007, XE3, DX10
Re:Clanky ohledne FireDAC?
« Odpověď #16 kdy: 25-06-2018, 20:32:14 »
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.



Offline Delfin

  • Padawan
  • ******
  • Příspěvků: 1652
  • Karma: 65
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
Re:Clanky ohledne FireDAC?
« Odpověď #17 kdy: 25-06-2018, 22:45:06 »
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.

Tema je to urcite uzitecne (pisu si ;)). On totiz FireDAC mimo Firebird a InterBase DBMS podporuje jen savepointy uvnitr transakci.
I'm a soldier, so don't panic! I know the underground! I like WTFPL license! No more Google, go duck, go!

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 2444
  • Karma: 131
    • Verze Delphi: D2007, XE3, DX10
Re:Clanky ohledne FireDAC?
« Odpověď #18 kdy: 26-06-2018, 08:47:55 »
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.
« Poslední změna: 26-06-2018, 08:50:27 od pf1957 »

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 2444
  • Karma: 131
    • Verze Delphi: D2007, XE3, DX10
Re:Clanky ohledne FireDAC?
« Odpověď #19 kdy: 17-08-2018, 15:04:31 »
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.

Offline miroB

  • Hrdina
  • ****
  • Příspěvků: 400
  • Karma: 16
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
Re:Clanky ohledne FireDAC?
« Odpověď #20 kdy: 17-08-2018, 20:10:55 »
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.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 2444
  • Karma: 131
    • Verze Delphi: D2007, XE3, DX10
Re:Clanky ohledne FireDAC?
« Odpověď #21 kdy: 17-08-2018, 23:20:32 »
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

Offline miroB

  • Hrdina
  • ****
  • Příspěvků: 400
  • Karma: 16
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
Re:Clanky ohledne FireDAC?
« Odpověď #22 kdy: 17-08-2018, 23:39:34 »
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čí.

 

S rychlou odpovědí můžete používat BB kódy a emotikony jako v běžném okně pro odpověď, ale daleko rychleji.

Upozornění: do tohoto tématu bylo naposledy přispěno před 120 dny.
Zvažte prosím založení nového tématu.

Jméno: E-mail:
Ověření:
Datový typ v Delphi, který má True a False: