ADO, jak spravne detekovat a osetrit restart sql serveru nebo vypadek sluzby

[pf1957]

spis me prekvapilo ze ado takove situace nema nijak podchyceny a musi se brutalne neco zapsat aby se zjistilo ze je server hin.

Prece kdyz nekdo chce prodavat komponenty, ktere maji free alternativu, tak musi neco pridat, ne? Proc by si to jinak nekdo kupoval?

[rob.]

diky za vsechny tipy, jeste bych se rad zeptal na jednu vec, uz mam osetreny vypadek spojeni - v try bloku zachyceni a v pripade selhani jsem si napsal funkci reconnect, ktera spojeni obnovi se vsemi datasety. Vse funguje. zaznam se ulozi a jede se dale. Ale zjistil jsem, ze kdyz se sql server behem prace s programem vypne (a zustane vypnuty), program mi i v tom try bloku zatuhne na tak dlouho dokud se server nezapne, treba 10 minut - potom aplikace odtuhne a teprv zachyti vyjimku a provede obnoveni. Cekal bych, ze po vyprseni nejakeho timeoutu nastane vyjimka, ktera se v try bloku zachyti a podle toho se zaridim - zkusim pripojeni pozdeji apod, jenomze vyjimka nenastane program je tuhy tak dlouho dokud se server nezapne, teprve pak nastane vyjimka. Kdyz je server vypnuty uz pri spusteni programu tak to jde zachytit normalne, zobrazim hlasku ze je nedostupny atd, popisovany problem nastane pouze kdyz se sql server vypne pri aktivnim spojeni.

[Radek Červinka]

U ADOConnection se da speecifikovat CommandTimeOut a ConnectionTimeOut. Mozna i to same primo u Query.

[vladyk]

Ještě to někoho zajímá? 

...pouziti bloku try... ale pouzivat to pred kazdym query open ?...

Já tedy nevím jak kdo, ale osobně mám jakékoliv Query "zapouzdřené" ve funkci, která je idiotensicher a vrací jednu z množiny hodnot "TQueryResult". Zas takové zdržení to v běhu aplikace není a robustnost je výrazně vyšší, což je pro mne rozhodující. A pokud je aplikace bezobslužná a výsledkem je nějaký ten "qrErrorX", tak není problém dopsat k tomu obsluhu, klidně i s timerem (ke zdržení a robustnosti stejný postoj).

Mám nasazené nějaké datové "mixery", které po nocích přenášejí ekonomická (=citlivá) data mezi účetními programy různých firem a za léta provozu to spadlo jen párkrát - když autor některého účetnictví něco změnil a neohlásil to. A v tom případě bylo v logu napsáno "změna datové struktury"...

[RomanZ]

Přesně jak píše vladyk, taky mám ve zvyku psát "jakékoliv Query "zapouzdřené" ve funkci".
Přesněji - mám funkci, do které předávám SQL a SQL parametry jako parametry. Jde o to, že pak mám ošetření všech SQL záležitostí na jednom místě a nemíchá se to s obchodní logikou.
Totiž ono kromě výpadku nebo nedostupnosti SQL serveru je třeba myslet i na ošetření dalších chyb, na transakce, na ošetření deadlocků apod., takže ten kód pro komunikaci s databází je s rostoucími zkušenostmi stále složitější a není šikovné ho udržovat na více místech.

[vladyk]

...ten kód pro komunikaci s databází je s rostoucími zkušenostmi stále složitější a není šikovné ho udržovat na více místech.

Tesat

Já jsem se s léty dopracoval do stavu, kdy prakticky každé (zájmové) tabulce v katalogu odpovídá v Delphi konzoli nějaký objekt, ten obsluhují nějaké na míru uplácané funkce (LoadXObject, InsertOrUpdateXObject...) a v těch je zašitá ta "idiotensicher" univerzální funkce OpenOrExecSimpleXQuery. A výsledky funkcí jsou obvykle nějaké množiny stavů, kterým odpovídají nějaké datové (výčtové) typy. Pak se dá velmi snadno reagovat na jakýkoliv podchycený stav celé databáze a na obsluhu stačí vyhodnotit pár bajtíků.