Zapouzdření SQLite pro Delphi

14.4.2010 19:07:29 #

Ad ZEOS:
Pouzivali jsme (naposledy 6.6.4-stable) proti MySQL a PostgreSQL  v 7x24 provozu bez problemu. Ve verzi 6.6.1BETA byly memory leaks ve spojeni s SQLite viz ticket #60 v Mantisu, coz by melo byt od 6.6.2 opraveno.

Ad Aducom:
Byly tam nejake potize s finalizaci stavu VM viz http://www.aducom.com/cms/e107_plugins/forum/forum_viewtopic.php?2198.

Ale ani ZEOS ani ADUCOM jsme po opravach  chyb ve spojeni s SQLite znovu netestovali a nepouzili - zustali jsme u vlastni connectivity.

pf1957

22.11.2010 14:25:28 #

Na http://www.filedepot.eu/ jsou ke stazeni freeware komponenty pro SQLite3, zatim pro Delphi 7, Delphi 2007 a Delphi 2010. Dalsi pribudou. Podminkou je pouze velmi jednoducha registrace.
Podporuji kodovani UFT-8, UTF-16 little endian i big endian. Dale podporuji diakritiku v nazvech db objektu (tabulek, poli, indexu, triggeru, pohledu...).
Vzhledem k tomu, ze jde o me dilko, uvital bych nejakou odezvu. Dekuji.

Ivan Sivak

14.1.2011 3:36:39 #

to vypadá dobře :)

SuD

21.3.2011 22:11:32 #

K mým SQLite3 komponentám na http://www.filedepot.eu/ jsem uvolnil zdrojový kód. Mělo by to být kompilovatelné od Delphi7 až po DelphiXE. Asi i Delphi6, ale tohle jsem netestoval.
Taky jsem tam opravil pár chyb.

Ivan Sivak

22.3.2011 14:05:25 #

tak mi to hlásí nějaké chybějící věci sql3_reg.dcr

Petr Šrámek

22.3.2011 16:57:54 #

No jo, na ikony, jsem zapomněl. Už by to melo byt OK.

Ivan Sivak

5.8.2011 15:01:02 #

Zdravím. Chtěl jsem to vyzkoušet, ale nevím, kde mám najít sqlite3.dll . Je správně, že jsem stáhl zip soubor se sqlite3.dll ze stránek http://sqlite.org a jenom k němu v demu naklikal cestu? A bude toto zapouzdření ThreadSafe? V zásadě by mi stačilo, kdybych mohl z jedné aplikace zapisovat a současně z druhé (přes síť) číst. Nebo je ThreadSafe už sqlite samo o sobě? A ještě - nenašel jsem v sivak3.zip nikde licenci. Co tedy, prosím, znamená "K mým SQLite3 komponentám na http://www.filedepot.eu/ jsem uvolnil zdrojový kód"? Děkuji Martin Prát

Martin Prát

5.8.2011 15:11:54 #

Ano, knihovnu sqlite3.dll je nutno stahnout ze stranek sqlite3.org,
protoze prave tato DLL je databazovy engine pro sqlite3. Me
komponenty jsou pouze pouze jakysi interface k teto knihovne.
Se zapisem a ctenim (z ruznych aplikaci) ktery pozadujes, by nemel
byt problem.
Jinak komponenty jsou free.

Ivan Sivak

5.8.2011 16:27:52 #

Dík. Já to vyzkouším a a kdyby se mi to podařilo použít (zatím to na to nevypadá), ještě se ozvu ohledně přesné licence. Možná, kdybys ke zdrojákům připsal, že je to třeba NewBSD podle Davida Grudla ( http://doc.nette.org/cs/license#toc-new-bsd-license ) , tak to opravdu uvolníš, ale sám se v tom moc nevyznám. Většina "free" licencí neumožňuje otevřený software použít v rámci uzavřeného (a to i částečně uzavřeného v libovolné části, tedy i v těch, které programátor chtě nechtě odněkud přejímá), čímž v podstatě znemožní použití vůbec. Martin

Martin Prát

5.8.2011 16:30:19 #

Jenže ona je vlastně licencovaná i ta licence, co jsem psal. Tak nevím.

Martin Prát

2.2.2013 14:30:49 #

Martin Prát, zaujimalo by ma ako si uspel. SQLite je podla mna skvela vec - pre lokalne databazy. Pouzivam ju masivne uz niekolko rokov na tvorbu trednov, logov a na ukladanie nastaveni pre aplikaciu. Osobne som pouzival LibSQL, ktoru som osobne pomahal autorovi vylepsovat:

http://sourceforge.net/projects/libsql

Projekt je uz viac menej mrtvi, ale ja som si ho lokalne este stale upravoval pre svoje potreby, plus som ho udrziaval napriec novymi verziami delphi.

Dnes by som asi uprednostnil Synopse framework, je to obdivuhodna nadstavba. Autor je garanciou samou o sebe. A najviac ma zaujala moznost zakompilovat sqlite priamo do aplikacie bez nutnosti distribuovat dll.

Libsql bola tusim threadsafe, priznam sa ze ju mam uz tak zapuzderenu vo svojich projektoch ze ani napamatam presne. Ale v jednom v tvojich komentarov som si vsimol ze chces citat sqlite databazu po sieti. Tu som ja v minulosti raz dost nepekne narazil. Vramci viacerych klientov beziacich na jednom PC, sqlite nema problem. Funguje pekne, ale pri pristupe cez siet je to uplne nieco ine, dokonca je to problem aj ked sa jedna len o citanie. V mojom pripade som mal jednu app, ktora kazdych par sekund nieco zapisovala. A mal som asi 5 klientov na sieti ktore sporadicky raz dvakrat do dna citali data. Uz pri takom pocte sa to zvyklo neraz zahriznut. Uz si presne nepamatam ci to bol problem wrappera alebo sqlite, resp. skor windowsu v tom ako manazoval pristup k suboru na disku. Ale tusim i na webe sqlitu neodporucali citat databazu po sieti. Ja som to pracne vyriesil opakovanymi volaniami try...except v cykle s nejakymi prodlevami. A ked sa to nepodarilo ani po 10tich pokusoch tak som celu appku restartoval. No bol to des. Funguje to sice uz roky do dnes, ale s casu na cas sa to aj tak hrizne. Nikdy viac, bohuzial to bolo robene v podniku v ktorom nam informatici absolutne nedovolili pouzivat nejaky sietovy db server. Jedinne co nam dali bol jeden sietovy zdielany disk. Dnes by som to urobil radsej cez *.ini subory :D. Citanie a zapis funguje pekne i po sieti.

Daniel Andrascik

6.2.2013 17:49:04 #

Ahoj. Bohužel i po té době musím konstatovat, že jsem neuspěl naprosto nijak. Celý projekt dělám ve firmě, která 15 let ukládá data do běžných souborů a "celou dobu to spolehlivě funguje". Mezivláknovou a meziprocesovou synchronizaci nikdy nikdo příliš neřešil, občas se ve zdrojovém kódu vyskytuje kritická sekce, což v době pomalých počítačů, pomalých sítí a nezabezpečenych systémů stačilo na mnohaletý kontinuální bezproblémový provoz. V jistém smyslu to opravdu vše funguje výborně, ale stačí, aby někdo u zákazníka zapojil do sítě W2K počítačů jeden s Windows 7, změní se odezvy v síti a často i přistupová práva. Veškeré pokusy z Delphi komunikovat s některou větší databází ukázaly jen to, jak je Delphi zabugované a volně šířené komponenty ještě více. Teď už se opravdu schyluje k první KOMPLETNÍ předělávce. Po skoro roce pořád nevím, v čem ukládat data. Problém je, že to jsou data kritická a kontinuální, přitom zákazníci neplatí tolik, aby bylo
možné nasadit ani MS SQL Server, ve free verzi je zase problém s velikostí dat. Ono to někde opravdu jede bez zásahu a jediného restartu už třeba desátý rok bez ohledu na všechny požáry, nefunkční sítě i lidské chyby, které se za tu dobu v přislušné fabrice objevily. Nezdá se to, ale spolehlivost není zrovna silnou stránkou kteréhokoliv moderního řešení. Historian, OPC, Modbus, MSSQL a veškerá další profesionalní řešení zatím všude přinesla při dlouhodobém provozu problémy a většinou jsem byl rád, že máme k dispozici tu stařičkou souborovou zálohu. Zatím to vypadá, že i u té připravované aplikace budu budu primární data ukládat nadále souborově, ale tady bych raději použil nějakou rozumnou organizaci dat, třeba právě SQLite. Připravovat pro zákazníka programy pro převod dat v případě drobné změny měření není zrovna přijemné. Přitom přidání či výměna některé měřící jednotky nejde předem naplánovat, hardware se mění a formát dat tedy nutně také. A až pro zálohy a zpracování dat bych rád použil síťovou databázi, ve které bude i značná část aplikační logiky. Hlavně ta, která závisí na legislativě, nikdo neví, kdy komu v Bruselu rupne v makovici. Takže asi by stačilo, kdyby do SQLite jedna aplikace, která bude sloužit pouze pro sběr dat, zapisovala, a druhá, která bude data vlastně jen přeposílat do databáze (pravděpodobně MSSQL, pokud se s daty vejdeme do free verze) by z ní četla na STEJNÉM počítači. Chápu dobře, že takové požadavky jsou prověřené a odzkoušené? Dík, Martin

Martin Prát

6.2.2013 18:15:02 #

Pokial bude aplikácia zapisujúca do SQLite súboru aj aplikácia ktorá ten SQLite súbor následne číta (a posiela dáta na nejaký db server) bežať na tom istom stroji (windows, NTSF) tak by s tým nemal byť problém. Odskúšané to mám x krát za tie roky, aj masivnejšie, ale tuším v prevádzke 24/7 som to zase nemal. Ale ani na webe som nenarazil že by s tým mal dakto problém. V rámci jedného PC by nemal byť problémom ani súčasný zápis do SQLite. V takom prípade sa môže stať že jedna aplikácia može nachvíľu zatuhnúť, pretože druhá začala tranzakciu. Ale v momente ukončenia tranzakcie sa aj tá čakajúca aplikácia pohne a pokračuje dalej, to mám tiež vyskúšané (môže to byť aj špecifikum wrapera). Ale pokial zapisuje len jedna palikácia, tak tu nevidím priestor na žiadne problémy. Samozrejme treba mať dobrý wrapper. Vačšinu tu spomeutých považujem za kvalitné wrapere. Aplikácií ktoré mi jednoužívateľsky zapisujú do SQLite súboru v režime 24/7 mám nasadené na desiatky. Vytvorili už hádam stovky gigabajtov databázových súborov (delené samozrejme na manšie súbory). Z corrupted súborom som sa stretol asi len raz, ale to uz odchádzal hardver na tom stroji (o par tyzdnov ten stroj klakol uplne)

Daniel Andrascik

6.2.2013 22:32:46 #

OK, dík za doporučení. Zkusím tedy SQLite, ozvu se s případnými problémy cca za měsíc. Martin

Martin Prát

2.9.2013 17:07:44 #

Ahoj. Postupně zapojuji SQLite do našeho projektu. Mám ale obrovské problémy s výkonností. Je normální, aby zápis jednoho řádku do jednoduché prázdné tabulky trval cca 200 ms? SQL vypadá takto:

DROP TABLE IF EXISTS "dataA";
CREATE TABLE "dataA" (
  "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
  "minute" integer NULL,
  "sample" integer NULL
);

INSERT INTO "dataA" ("minute", "sample") VALUES (22968809,  2);

Vždyť to jsou jen dvě celá čísla a tabulka je prázdná (i když je pak plnější, doba zápisu zůstává přibližně stejná). Potřebuji takto po jenom řádku zapisovat cca 50x každých 10 s, což databáze vůbec nestíhá. Dělám to mimo wrapper, zdá se, že jde o vlastnost samotné databáze. Když to samé udělám v MS SQL Server 2008 Express, časy jsou neměřitelně malé!

Martin Prát

2.9.2013 17:34:28 #

Ahoj. A když ji pustíš v transakci?
BEGIN TRANSACTION;
INSERT INTO "dataA" ("minute", "sample") VALUES (22968809,  2);
COMMIT;

Petr Šrámek

2.9.2013 17:56:49 #

Jednoznacne je potrebne viacero insertov uzatvarat do tranzakcii. Ja som jednotlive inserty nikdy nemeral a vacsie ukladania som vzdy uzatvaral do tranzakcii. Rychlost zapisu u SQLite enormne ovplynvuje pragma synchronous - http://www.sqlite.org/pragma.html#pragma_synchronous . Defaultne je nastavena na vysoku bezpecnost (FULL) a vtedy je rychlost viacnasobnych zapisov bez tranzakcii naozaj mala. Vynimocne som ju vypinal len pri statistickom ukladani ked som ukladal udaje ktore neboli zivotne dolezite. Ale v inych pripadoch som vzdy tuto pragmu nechaval nastavenu na FULL! Jeden moj kolega robil raz s SQLitom registracnu pokladnicu a tam bezpecnost dat bola na prvom mieste. So zapnutym synchronnym zapisom sa mu nepodarilo nikdy databazu poskodit a to vykonal vtedy nespocet tvrdych resetov pocas vykonavania zapisov do databazy.

Daniel Andraščík

2.9.2013 18:03:54 #

A cetl jsi bod #19 tady www.sqlite.org/faq.html?

pf1957

2.9.2013 18:06:27 #

A protoze jsi vyse mel nejake dotazy ohledne simultanniho pristupu k SQLite, tak bych ti (asi pozde) doporucil bod #5 tamtez.

pf1957

2.9.2013 18:25:39 #

Ahoj. Dík za rychlé reakce. FAQ jsem četl. Tam píšou o 60 transakcích za sekundu u běžného disku, což by mi úplně stačilo. Já to teď zkoušel i na novém prázdném rychlém disku a víc jak 6 za sekundu se jich nikdy nepovedlo. Bohužel do transakce mohu obalit jen malé části po několika insertech, zapisuje se střidavě z různých aplikací. Lze u základní thread safe verze začít transakci z jedné aplikace a zakončit z jiné?

Martin Prát

2.9.2013 20:00:35 #

Nie, to urcite nie je mozne. Navyse ako nahle v jednej aplikacii zacnes tranzakciu, ostatne aplikacie nemaju sancu zapisat do tejto db uz nic. Bude ti hlasit chybu - database is locked. Sak si kludne stiahni orig. konzolovku http://www.sqlite.org/2013/sqlite-shell-win32-x86-3080001.zip a spusti ju dva krat nad jednym a tym istim databazovim suborom a spustaj tranzakcie z jednej aj druhej apky a potom skusaj robit inserty. Zaujimavostou ktoru som teraz zistil je ze samotny prikaz "BEGIN TRANSACTION" databazu este nezamkne, stale ostatne aplikacie mozu vykonavat zapisy. Az v momente ked aplikacia ktora zacala robit tranzakciu vykona prvy zapis az vtedy dojde k zamnknutiu databazy. Potom uz naozaj ostatne aplikacie nic nezapisu a budu dostavat chybove hlasenie.

Daniel Andraščík

2.9.2013 20:03:34 #

SQLite uz moc vhodne na simultalne zapisy nie je. Da sa to zvladnut, ale musis si osetrit vsetky tieto neprijemnosti so zamknutou databazou sam. Ja som mal vzdy len jedneho zapisovatela a viacerych citatelov. To nerobilo ziaden problem.

Daniel Andraščík

2.9.2013 23:45:16 #

A mam dojem, ze se v takovem pripade  musi buildnout pro multithreaded rezim viz www.sqlite.org/threadsafe.html.

Osobne bych SQLite pro takovou sitovou aplikaci nepouzival a sahnul po Firebirdu.

pf1957

3.9.2013 0:42:00 #

Podla predchadzajucich sprav to nie je sietove pouzitie, mali by to byt vsetko aplikacie beziace na jednom pc. To este SQLite zvlada, hoci samozrejme sa nemoze rovnat multiuser databazam. Co v poslednej dobe citam na nete tak firebird je dobra volba. Neviem jak je to s embeded verziou, ci je potrebna instalacia, alebo ju staci mat pribalenu k aplikacii.

Daniel Andraščík

3.9.2013 1:20:28 #

Ked tak pozeram na featurky toho Synopse frameworku, tie by mohli vyriesit problemy s viacuzivatelskym pristupom. Oproti ostatnym databazam ako firebird a pod by to stale ostalo tzv. "zero-configuration" a v "cisto delphi rezime" bez dll a externych aplikacii .

Daniel Andraščík

3.9.2013 8:20:54 #

FB  Embedded je RDMBS v DLL stejne jako SQLite, ale v normalni verzi je to slusny SQL server, ktery ma sice pomalejsi vstrebavani novinek ze sveta SQL, ale to co umi dela poradne. A treba v oblasti SP nevypada, jako kdyz pejsek s kocickou pekli dort jako MSSQL, ani neni treba explicitne onanovat s kurzory jako u Oracle. Navic ma domeny, coz je obdoba deklarace typu v jazykach s typovou kontrolou, coz je featura, kterou u ostatnich DB silne postradam.

pf1957

3.9.2013 11:15:49 #

Dík za všechny náměty a komentáře. Původně jsem dotaz psal i do jiného fóra, kde ale příspěvek dlouho čekal na zveřejnění a tak jsem se zeptal tady, teď mám odpovědi na obou. Podle všech reakcí to vypadá, že na Windows a běžném disku zvládne SQLite v základním buildu opravdu průměrně cca jen 6 transakcí za sekundu. Nějak si s tím poradím. Problém je, že naše aplikace musí umět jet mnoho let bezúdržbově v uzavřené bedně. Zkoušeli jsme různé DB enginy a zatím všechny už po roce provozu vykazují pokles výkonnosti bez ohledu na automatické defragmentace. V MSSQL dokonce vždy po několika měsících až letech došlo k "nakopnutí" nejčastěji používané tabulky. Většinou tam visel nějaký zámek, což se ještě dalo vyřešit, byť ne automaticky. Už jsme ale měli i případ, že tabulka byla prostě dokonale zničená od určitého ID dál a data jsme z ní už nedostali. Proto jsme se nakonec rozhodli pro SQLite, kde budeme mít veškerou práci s daty i zálohování pod vlastní kontrolou. V průmyslu jsou někdy nutné kompromisy. Například když celá továrna jede na starých Windows NT, nemůžeme jim do sítě připojit počítač s jiným OS, protože administrátorovi sítě pak některé věci nejdou nastavit a podobně. O vzdáleném přístupu si můžeme nechat jen zdát atd. Takže programujeme hlavně v Delphi <= 2006 a na jejich nestabilitu na Windows 7 nadávám několik hodin denně. Problém je neuvěřitelné množství vnitřních závislostí ve starých kódech a za 30 let se aplikace tak rozrostly obsahem i množstvím "klonů", že napsat to lépe odznovu je nemožná práce, i když se o ní ve volnějších chvílích snažím. Za dva roky, co v tomto oboru dělám, řeším s neustále narůstajícím zpožděním zpožděním hlavně drobné opravy a malé předělávky, čímž vznikají jen další a další klony, kde jenom udržet aktuální zdrojové kódy je práce téměř na plný úvazek. Na naprosté většině míst se naše data ukládají "postaru" sekvenčně do binárních souborů a v podstatě se ukazuje, že je to nejspolehlivější cesta. Někde se jen jednou za 10 let vymění umírající harddisk a filtry větráků. Ideální by bylo nahradit binární soubory téměř stejně velkými SQLite databázemi a ponechat např. zálohování tak jak je, v průmyslové oblasti není jednoduché přejít na něco zcela nového. Holt zkusím zápisy ještě nějak poladit, alespoň část insertů do transakcí uzavřít mohu a asi napíšu jednoduchý engine s frontou pro data z dalších aplikací, který také zapíše všechna data s jedním timestampem v jedné transakci bez ohledu na jejich zdroj.

Martin Prát

3.9.2013 11:47:57 #

D2007 tiez pozuzivam roky a su stabilnejsie ako XE, XE1, XE2, XE3 dokopy i bez FIXPackov :). XE3 uz pouzivam pre novy vyvoj (koli generikam a extended RTTI), D2007 uz len pre udrzbu starych projektov, alebo pre zriedkavy pripad kedy chcem este male exe pod 1MB (viem ze starsie robia este mansie exe ale na stovkach kilobajtov mi nezalezi). Radku, co je to za opravu ta oprava toho debuggeru? Ta oprava je sucastou fixpacku, alebo je to z ineho sudka?

Daniel Andraščík

3.9.2013 12:03:17 #

Martin Prat: pacia sa mi tvoje skusenosti, resp. skusenosti tvojej firmy s priemyselnym protstredim. Moja firma tiez pracuje pre priemyselnu oblast, ibaze len cca 5-6 rokov a nemame az takych hardcore zakaznikov ktori maju v celej fabrike len WinNT a nase ulozene data nie su az tak kriticke. Ked sa nahodou raz stane ze zakaznik nebude vediet kolko mu linka vyrobila kusov za minuly mesiac, alebo kolko mu zozrala elektriny tak bude frflat, ale nakoniec si to zisti zo skladu, alebo expedicie. V tomto sa mi ale sqlite osvedcil, bud pre kazdy mesiac, alebo rok som zakladal novy databazovy subor. A taketo ukladanie mi fakt v uzatvorenej krabici funguje uz roky bez udrzby az dokial neodide harddisk. Je pravda ze keby to robil nejaky DB server tak by sa to bez absolutnej udrzby z pohladu viacerych rokov asi nezaobislo. Takze tvoje rozhodnutie pouzivat sqlite ako nahradu za ukladanie do binarnych fajlov je podla mna dobre, otazkou ostava uz len ta rychlost. BTW spominas ze chces urobit nejaky jednoduchy engine pre frontu z viacerych aplikacii. Skus pouvazovat nad Synopse, mozno by si to uz mal v ramci tohto frameworku hotove ;)

Daniel Andraščík

3.9.2013 12:04:09 #

Nemam cas se tim zabyvat a uz roky jsem nic noveho s SQLite nedelal, ale do verze 3.5.6 jsme ji pouzivali hodne a v roky nepretrzite bezicich systemech a rozhodne pocet insertu odpovidal otackam HD.

Ale kdyz se divam na ten tvuj kod, tak ty tu mluvis o insertech, ale jestli jsem te pochopil, tak ve skutecnosti delas DDL prikazy jako drop table a create table.

Ovsem takhle se s DB nepracuje !!! Tabulka se vytvori prave jednou a pak se s ni pomoci  DML prikazu operuje s jejim obsahem !!!

pf1957

3.9.2013 14:59:04 #

aha, vdaka. 64bit windows nepouzivam, preto som si to nevsimol. Rozne priemyselne softwery nestihaju drzat krok z IT svetom a mnohe z nich na 64 bitoch nefunguju

Daniel Andraščík

3.9.2013 15:33:32 #

pf1957: Samozřejmě jsem dělal jen ten INSERT, uvedl jsem i strukturu.
Ostatní: Máme zakoupené Delphi 5, 6, 2006 a XE2. Mohu tím použít i 2007 a jsou na Windows 7 64bit výrazně stabilnější než 2006? Neustále řeším nejen to, že Delphi spadly, ale že při tom zničily aktuální projekt a zdrojáky samy přepsaly starší verzí, musím zálohovat tak 20x denně. Některé projekty byly přepsány do XE, které ale při jejich editaci občas padají také a ještě k tomu u výsledných aplikací pomalu, ale jistě stoupá alokovaná paměť, což pro mnohaleté použití nelze. Není to zřejmě v našem kódu a nepomohly ani různé pluginy pro sledování leaků. Ve Visual Studiu bych takový problém řešil tak do půl hodiny, v Delphi jsme to nakonec vzdali. Trochu podezřívám ovladač MSSQL a komponentu TChart, ale není čas to více řešit, stejný kód přeložený v Delphi 2006 jede bez leaků. Aplikace, které budou zapisovat do SQlite, raději vyvíjím ve Visual C++, kde mám vše pod kontrolou. V Delphi ale zůstanou starší rozsáhlé projekty a minimálně v první fázi i aplikace pro čtení a zobrazení dat. Bohužel v nich nebylo nadefinované žádné rozhraní, data se čtou z mnoha míst kódu chaoticky, ale i tak to bude rychlejší, než je vyvíjet znovu. Například mají UI optimalizované na rozlišení monitorů, které v dané továrně zrovna jsou na konkrétním počítači a to v celém zdrojovém kódu na náhodných místech. MVC nebo alespoň Doc/View zřejmě považovali tvůrci za sprosté slovo :-)

Martin Prát

3.9.2013 18:52:01 #

a jeje, mas to hodne zaujimave martine :)

Daniel Andraščík

23.9.2013 16:19:42 #

Ahoj. Občas mám výpadek v aplikaci, která nyní jako jediná zapisuje do SQLite databáze, když současně čtu z Admineru (přes PDO). Je to v pořádku? Děje se to dost zřídka a zatím jsem neodchytl výjimku, nějak jí vnitřně obslouží Kompex wrapper, ale občas je v zapsaných datech díra. Debugger VS se zastaví v obsluze výjimky, ale zatím jsem nezjistil, odkud pochází, výjimky jsou tam řešené dost zmateně. Myslel jsem, že zámky jsou jen v době zápisu. Ono je to tak, že čtení může u SQLite 3 v defaultním nastavení znemožnit zápis? Nemělo by to v takovém případě čekat na timeout? Ten mám defaultní, což je, myslím, jedna minuta. Nebo je pro zápis jiný než pro čtení?

Martin Prát

25.9.2013 0:51:55 #

Oprava: Není to v celé v jedné transakci, ale rozděleno do několika po zapisovaných 14400 řádcích (denní záznam s deseti řádky za minutu). Jak je vůbec možné, že v takovém případě chybí v tabulce jednotlivé řádky? Indexy jsou zrušené a znovu vytvořené po ukončení poslední transakce.

Martin Prát

25.9.2013 15:50:43 #

Hmm, ja som sa nestretol ze by sa mi stracali zaznamy. Skor to vyzera tak ze pri vyskyte nejakej vynimky sa neukonci tranzakcia a nejakym sposobom sa opusti, pripadne sa automaticky "rollbackne". Asi by som zacal hlbsie analyzovat wrapper. Sam tvrdis ze obsluha vynimiek je v nom nejaka zmatena. Uz som videl wrapere ktore automaticky po vynimke volali rollback. To by vysvetlovalo preco sa strati par zaznamov.

Daniel Andraščík

25.9.2013 16:04:10 #

To bych si dokázal představit. Jenže v jedné transakci bylo vždy těch 14400 INSERTů a chybělo pak několik jednotlivých řádků. Ale samozřejmě musím ještě vše překontrolovat, viděl jsem to jen jednou a nepodařilo se to reprodukovat znovu. V každém případě otázka zní -může být SQLite databáze zamčená pro zápis jenom kvůli současnému čtení?  A to dokonce tak, že se zápis okamžitě nepovede, místo aby čekal na nějaký timeout? Timeout ale může být špatně nastavený z wrapperu, já jsem vše nechal defaultní.

Martin

26.9.2013 16:11:36 #

Pochopil-li jsem to dobře, mělo by to řešit nastavení PRAGMA journal_mode=WAL. Otestuji a uvidím, teď už vím jistě, že šlo o zámek databáze pro zapisující aplikaci při čtení z jiné aplikace.

Martin

26.9.2013 16:22:52 #

som zvedavi na vysledok testovania

Daniel Andraščík

31.10.2013 21:52:11 #

Add DiSQLite: dospela do verze 5, a chce zaplatit update ze 4x (kterou mam koupenou) na verzi 5. Tak jsme si vymenili par mailu, a pochopil jsem, ze podpora iOs Android zatim neni v planech:-( ...presna fraze je ze "zatim sleduji trh a rozhodnu se" ...takze je cas hledat nejakou nahradu pro multiplatformni vyvoj:-(

bullhead