Autor Téma: SQLite + FireDAC + UDF nevracajú nadefinovaný dátový typ v rámci SELECT  (Přečteno 799 krát)

Offline Miroslav Baláž

  • Plnoletý
  • ***
  • Příspěvků: 124
  • Karma: 4
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
1. SQLite umožňuje dátum typu DateTime (Property v Connection)
2. V SQLite som si nadefinoval funkcie, obdobné ako má Access. Kvôli kompatibilite s Excelom. Super.
3. Až pokiaľ som ich nepoužil v rámci SELECT. Tam funkcia s návratom DateTime, vracia hodnoty typu Double. Pritom mám skontrolované,  že na odchode z funkcie je to jasný VARIANT typu dátum. Takže sa to po.. kazí niekde v rámci FireDAC.
4. Správny datový typ výsledku potrebujem nielen pre zobrazenie, ale aj ako vstup do ďalšej funkcie.
5. Funkcie môžu byť vnorené, napr. v tvare: Fn1( Fn2() ), preto nemôžem použiť techniku:  SELECT Datum AS DatumX::DATETIME
6. Ak si vytvorím novú tabuľku a dané pole nadefinujem ako DATETIME, tak doňho nasypem údaje cez INSERT INTO .. SELECT a všetko je OK. Double z funkcie sa stane pôvodným korektným dátumom. Následne SELECT nad touto tabuľkou, dáta správne zobrazí a vo funkciách sa Datum správa ako DateTime.  ALE TO NIE JE CESTA, vytvárať pre každý SELECT novú tabuľlku.. Len som zdokumentoval, že DateTime typ FireDAC naozaj pozná.
7. Kapacita SQLite je pre moje účely inak perfektná (mimo iné, kľudne zhltne 100x väčšie dáta, ako je max pre MS Access. Spracovávam dáta z dopravy, kde je mesačne cca 7 GB nových údajov. Potrebujem ročné prehľady. Tu funguje OK. Zatiaľ spolu 40 GB bez problémov. Ešte len testujem. )
8. MS Access a SQLite ako jediné môžem prevádzkovať bez inšatalácie (u MS Access to nie je celkom pravda). Pre to "bez inštalácie" mám zase iný dobrý dôvod..
9. Access a SQLite ako jediné rozumné DB, ak vynechám C/S, prakticky nemajú limitované názvy stĺpcov a tabuliek.. Dokonca sa dajú použiť aj znaky nad 255, zrejme aj Unicode. Tu ide o kompatibilitu s Excelom..
10. SQLite a FireDAC s využitím techniky (zrejme ide o Array DML), poskytuje neskutočne rýchly zápis dát.
Náčrt techniky rýchleho zápisu:

Kód: [Vybrat]
FDQuery1.SQL.Text := 'insert into batch_demo values (:id, :name, :datum)';
  FDQuery1.Params.ArraySize := 10000;
  with FDQuery1 do
    begin
    Params[0].DataType := ftInteger;
..
    end;
  with FDQuery1 do
    begin
    Params[0].DataType := ftInteger;
..
    Params[2].DataType := ftDateTime;
..
    end;
  FDQuery1.Prepare;
  Conn.StartTransaction;
  j := 0;
  FDQuery1.OnError := nil;
  for i := 0 to FDQuery1.Params.ArraySize - 1 do
    begin
    FDQuery1.Params[0].AsIntegers[i] := i;
    FDQuery1.Params[1].AsStrings[i] := IntToStr(i);
    FDQuery1.Params[2].AsDateTimes[i] := ddt + j;
    Inc( j );
    end;
  iTimes := FDQuery1.Params.ArraySize;
  iOffset := 0;
  while iOffset < iTimes do begin
    try
      FDQuery1.Execute( iTimes, iOffset );
      Inc( iOffset, FDQuery1.RowsAffected );
    except
      on E: EFDDBEngineException do begin
        // Fix bad value
        FDQuery1.Params[ 0 ].AsIntegers[ E.Errors[ 0 ].RowIndex ] := E.Errors[ 0 ].RowIndex;
        // Adjust the row index to start execution
        iOffset := E.Errors[ 0 ].RowIndex;
      end;
    end;
  end;
  Conn.Commit;
  FDQuery1.Params.Clear;

Dôvody SQLite a FirDAC sú zatiaľ jasné, až na ten typ návratu z funkcie.
Že by bola len jediná možnosť prekopať FireDAC od návratu hodnoty z funkcie až po jej zobrazenie?
To by bolo asi dramatické. Tento problém zatiaľ neviem vyriešiť.

Potreboval by som pred Query.Open niečo takéto (samozrejme, že tak ľahké to nie je):
Kód: [Vybrat]
FDQuery1.FieldByName( 'Datum' ).DataType := ftDate;Čítal som príspevok od Delphin, na tému Field Mapping z 1.10.2017.
Mohol by mi pomôcť FieldMapping.?
Bohužiaľ docwiki nejde. Neviem, kde začať. Ďakujem.

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 3120
  • Karma: 30
    • Verze Delphi: XE7 professional
Problém je v tom, že SQLite pozná jedine typ string. Presnejšie, všetky údaje ukladá ako string. Keby si hľadal v témach, tak tam nájdeš môj príspevok, kde sa to zoširoka rozoberá.
Aby som to nemusel riešiť, tak ju nepoužívam. Zvolil som si FireBird. Aby si nepovedal
http://forum.delphi.cz/index.php/topic,15289.0.html

« Poslední změna: 22-11-2017, 13:24:19 od Stanislav Hruška »
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 2005
  • Karma: 103
    • Verze Delphi: D2007, XE3, DX10
3. Až pokiaľ som ich nepoužil v rámci SELECT. Tam funkcia s návratom DateTime, vracia hodnoty typu Double. Pritom mám skontrolované,  že na odchode z funkcie je to jasný VARIANT typu dátum. Takže sa to po.. kazí niekde v rámci FireDAC.
Nemichas hrusky s jabkama? TDateTime = type Double;.

Online Delfin

  • Guru
  • *****
  • Příspěvků: 610
  • Karma: 27
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
1. SQLite umožňuje dátum typu DateTime (Property v Connection)
2. V SQLite som si nadefinoval funkcie, obdobné ako má Access. Kvôli kompatibilite s Excelom. Super.
3. Až pokiaľ som ich nepoužil v rámci SELECT. Tam funkcia s návratom DateTime, vracia hodnoty typu Double. Pritom mám skontrolované,  že na odchode z funkcie je to jasný VARIANT typu dátum. Takže sa to po.. kazí niekde v rámci FireDAC.
4. Správny datový typ výsledku potrebujem nielen pre zobrazenie, ale aj ako vstup do ďalšej funkcie.
5. Funkcie môžu byť vnorené, napr. v tvare: Fn1( Fn2() ), preto nemôžem použiť techniku:  SELECT Datum AS DatumX::DATETIME
6. Ak si vytvorím novú tabuľku a dané pole nadefinujem ako DATETIME, tak doňho nasypem údaje cez INSERT INTO .. SELECT a všetko je OK. Double z funkcie sa stane pôvodným korektným dátumom. Následne SELECT nad touto tabuľkou, dáta správne zobrazí a vo funkciách sa Datum správa ako DateTime.  ALE TO NIE JE CESTA, vytvárať pre každý SELECT novú tabuľlku.. Len som zdokumentoval, že DateTime typ FireDAC naozaj pozná.
7. Kapacita SQLite je pre moje účely inak perfektná (mimo iné, kľudne zhltne 100x väčšie dáta, ako je max pre MS Access. Spracovávam dáta z dopravy, kde je mesačne cca 7 GB nových údajov. Potrebujem ročné prehľady. Tu funguje OK. Zatiaľ spolu 40 GB bez problémov. Ešte len testujem. )
8. MS Access a SQLite ako jediné môžem prevádzkovať bez inšatalácie (u MS Access to nie je celkom pravda). Pre to "bez inštalácie" mám zase iný dobrý dôvod..
9. Access a SQLite ako jediné rozumné DB, ak vynechám C/S, prakticky nemajú limitované názvy stĺpcov a tabuliek.. Dokonca sa dajú použiť aj znaky nad 255, zrejme aj Unicode. Tu ide o kompatibilitu s Excelom..
10. SQLite a FireDAC s využitím techniky (zrejme ide o Array DML), poskytuje neskutočne rýchly zápis dát.
Náčrt techniky rýchleho zápisu:

Kód: [Vybrat]
FDQuery1.SQL.Text := 'insert into batch_demo values (:id, :name, :datum)';
  FDQuery1.Params.ArraySize := 10000;
  with FDQuery1 do
    begin
    Params[0].DataType := ftInteger;
..
    end;
  with FDQuery1 do
    begin
    Params[0].DataType := ftInteger;
..
    Params[2].DataType := ftDateTime;
..
    end;
  FDQuery1.Prepare;
  Conn.StartTransaction;
  j := 0;
  FDQuery1.OnError := nil;
  for i := 0 to FDQuery1.Params.ArraySize - 1 do
    begin
    FDQuery1.Params[0].AsIntegers[i] := i;
    FDQuery1.Params[1].AsStrings[i] := IntToStr(i);
    FDQuery1.Params[2].AsDateTimes[i] := ddt + j;
    Inc( j );
    end;
  iTimes := FDQuery1.Params.ArraySize;
  iOffset := 0;
  while iOffset < iTimes do begin
    try
      FDQuery1.Execute( iTimes, iOffset );
      Inc( iOffset, FDQuery1.RowsAffected );
    except
      on E: EFDDBEngineException do begin
        // Fix bad value
        FDQuery1.Params[ 0 ].AsIntegers[ E.Errors[ 0 ].RowIndex ] := E.Errors[ 0 ].RowIndex;
        // Adjust the row index to start execution
        iOffset := E.Errors[ 0 ].RowIndex;
      end;
    end;
  end;
  Conn.Commit;
  FDQuery1.Params.Clear;

Dôvody SQLite a FirDAC sú zatiaľ jasné, až na ten typ návratu z funkcie.
Že by bola len jediná možnosť prekopať FireDAC od návratu hodnoty z funkcie až po jej zobrazenie?
To by bolo asi dramatické. Tento problém zatiaľ neviem vyriešiť.

Potreboval by som pred Query.Open niečo takéto (samozrejme, že tak ľahké to nie je):
Kód: [Vybrat]
FDQuery1.FieldByName( 'Datum' ).DataType := ftDate;Čítal som príspevok od Delphin, na tému Field Mapping z 1.10.2017.
Mohol by mi pomôcť FieldMapping.?
Bohužiaľ docwiki nejde. Neviem, kde začať. Ďakujem.

1. Connection definition parametr DateTimeFormat je jen zpusob jakym se budou hodnoty ukladat do DB. Jako ftDateTime by mel byt sloupec identifikovan nehlede na toto nastaveni.
2., 3., 4. Jak jsi definoval funkce? Externim modulem? Pomoci TFDSQLiteFunction?
5. Mozna bude treba; zkusim Tvou situaci nasimulovat, jen potrebuju znat odpoved na body 2. az 4.
6. Zna, protoze pouziva pseudo datove typy. "ALE TO NIE JE CESTA, vytvárať pre každý SELECT novú tabuľlku.." Tomu nerozumim, proc pro kazdy prikaz?
7. SQLite ma z vyroby limit kolem limit 140 TB. Access je dilo dabla. Docela me desi, ze se bojis instalace DBMS na ukor pripadne stability.
8. Na to dobry duvod neexistuje. Zkus prekvapit :)
9. Zacinam ziskavat predstavu o tom co existuje na tom Accessu.
10. Je rychle, jsi si jisty ze jej pouzivas nativne? Nastavujes Params.BindMode na pbByNumber?

Field mapping by pomoct mohl, ale nemuzes ho pouzit na prilis obecny typ. Je to ale spis naplast nez reseni. Potrebuju znat odpoved na ty body 2. az 4. Nebo nastinit reseni jako celku; staci v nejak minimalizovanem kodu.

P.S. docwiki si muzes pro Berlin prohlizet na http://web.archive.org.

Problém je v tom, že SQLite pozná jedine typ string.

To jo, ale FireDAC nabizi pestrou skalu pseudo datovych typu.
« Poslední změna: 22-11-2017, 16:28:20 od Delfin »
I'm a soldier, so don't panic!

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 3120
  • Karma: 30
    • Verze Delphi: XE7 professional
Citace
9. Access a SQLite ako jediné rozumné DB, ak vynechám C/S, prakticky nemajú limitované názvy stĺpcov a tabuliek.. Dokonca sa dajú použiť aj znaky nad 255, zrejme aj Unicode. Tu ide o kompatibilitu s Excelom..
Pri Access-e si nie som o tom celkom istý. Takže help pre 2007
Citace
Názvy polí môžu pozostávať z čísiel a písmen v maximálnej dĺžke 64 znakov vrátane medzier.
Citace
8. Na to dobry duvod neexistuje. Zkus prekvapit
K tomuto sa pripájam. To bola prvá vec čo ma dosť zarazila ;)

Ak chce niekto používať extrémne dlhé názvy polí, jedno kde, tak:
  • nevie čo robí, alebo
  • je blbec
Pre mňa je základ čitateľnosť a rýchla orientácia. To znamená, že hodím očkom po názve a musím okamžite vedieť o čo ide. Ináč to odvádza pozornosť a znižuje výkonnosť užívateľa.
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Offline Miroslav Baláž

  • Plnoletý
  • ***
  • Příspěvků: 124
  • Karma: 4
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
Práve posielam širšie objasnenie dôvodov. Myslím, že tam sú odpovede.

Online Delfin

  • Guru
  • *****
  • Příspěvků: 610
  • Karma: 27
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
Citace
Názvy polí môžu pozostávať z čísiel a písmen v maximálnej dĺžke 64 znakov vrátane medzier.
Citace
8. Na to dobry duvod neexistuje. Zkus prekvapit
K tomuto sa pripájam. To bola prvá vec čo ma dosť zarazila ;)

S tim souhlas, ale to je bod 9 :) Tam jsem jen "zoufal" (psat pohadky ve schematu proste nepatri [mimo komentare sloupcu], ale chapu to jako stary, amatersky vyrobeny system). Me spis zarazi bod 8., kdy chce nekdo ukladat 7GB/mesic na stroj kde se boji nainstalovat plnohodnotny DBMS. Takova data patri na "centralizovany", zalohovany server, k serveru pak (alespon jeden) administrator (takova ta opicka pred kterou hrozi nebezpeci urazu po letu vyrazeneho kusu hardware pri zmince slova Windows).

Práve posielam širšie objasnenie dôvodov. Myslím, že tam sú odpovede.

Jsem jedno velke ucho :) Byt mi par pratel v minulosti naznacovalo jiny organ ;D
I'm a soldier, so don't panic!

Offline Miroslav Baláž

  • Plnoletý
  • ***
  • Příspěvků: 124
  • Karma: 4
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
Delfin, veľmi kvalifikovaná odpoveď. Ďakujem.
Problém je trochu zložitejší na jednu výmenu názorov.
Tak aspoň rýchlo:
A.
Kompatibilita SQL a Excel je moja priorita. Už roky učím tieto predmety manažérov na Fak. manazmentu Univ. Komenského, BA.
Žiadna databáza, ktorá nejde z USB kľúča, ich neprinúti študovať nejaké ďalšie technické problémy. Ak sa majú naučiť nejaké funkcie, tak maximálne raz, určite už nie dvakrát.
SQL Access má 98% funkcií zhodných s Excelom. Excel ich má asi 375, SQL Acces z toho využíva asi 100. Sandobox je trochu problém. Niektoré fn sú tým blokované.
Ak majú tí moji pracovať doma, musí to šlapať. Hneď. Žiadne inštalácie. Žiadna blokácia.
B.
Kde som definoval funkcie?
Trochu Harakiri: priamo v "FireDAC.Stan.ExprFuncs".
Mám ho modifikovaný pod iným menom priamo v rámci projektu.
Odsledoval som ako je to tam pôvodné. Niekde som len pridal svoje Aliasy a pár funkcií som založil nanovo. Napríklad Format. Aby vyhovela tej z Accessu, dalo to dosť práce. U nej napríklad záleží na na type vstupných údajov. Access to zvláda komplexne (napríklad aj mimo mesiacov z rozashu 1..12, ale to nie je všetko). V Delphi potrebujem poznať vstupný formát. Podľa toho použijem buď FormatFloat, alebo FormatDateTime. Takže nie je iná cesta. Absolútne záleží na type Double, alebo DateTime.
Ale to nie je jediný prípad. Potrebujem to korektne a presne aj vo viacerých ďalších prípadoch. Nie je problém, aby som čokoľvek zamenil. Viď bod D.
C.
K UDF kódu. Nie, že by som ho nechcel sem poslať, ale sú to trochu dlhé texty.
Teraz som doučil. Dlhých 6 hodín. Som už nejak unavený na modifikácie. Ale spoľahlivo to ne/funguje v každej akokoľvek a kdekoľvek nadefinovanej funkcii.
Myslím, že pokiaľ som funkcie nepoužil v rámci SELECT, tak to nejak šlo. Teda ak by mali fungovať len ako math parser.  Akonáhle sú súčasťou SELECT, zabúdajú na typ DATETIME a tvária sa vo výsledku ako Double. To je veľký problém.
Zajtra v priebehu dňa môžem poslať jednoduchý vzor.
Je to obrovská škoda, lebo SQLite je inak prekvapivo šikovný nástroj.
Podotýkam, že som robil roky s Access enginou (ADO). Nie priamo v MS Access, ten som nikdy nepotreboval, ďalej v MS SQL Server, MS SQL Server Compact (na prvý pohľad sľubné, ale nepoužiteľné), MS SQL Server Local DB (nádejné, ale limitované na 11 GB), nanovo som skúšal FB local, dobre rozbehnuté, ale limit z názvami objektov je fatálny. Skúšal som aj Nexus DB, ale má limity podobne ako FB.
K prípadným limitom SQLite: Napríklad FULL JOIN som schopný simulovať. Trochu horšie je to s náhradou Transform, to chce analýzu dát a potom nagenerovať CASE .. WHEN. Ale to dám tiež. Ak by Access engina nemala hlúpe limity, tak by to bola dobrá databáza. Asi pred 12-timi rokmi som porovnával výkon Access a MS SQL. Fifty:Fifty. Boli to série SQL, čo bežali cca 20 minút. Niečo rýchlejšie v jednom, niečo v tom inom. Obe bežali na PC. Lenže ten s MS SQL bol dedikovaný. Veľká nadnárodná firma. Nešetrili. Ono sa to akoby nezdá, ale PC majú len jedného užívateľa. Ich výkon je preto ozaj dostatočný.
Mimochodm v SQLite je veľmi limitovaný aj UPDATE .. SET. Nemá možnosť JOIN, čo je drsné, ale také veci viem prekonať.
D.
Mám absolútne rozparsovaný vstupný text SQL. V dictionary mám podchytený každý jeden string/funkciu/pole/tabuľku/zátvorku, či znak, ktorý by nebol nejako inak pokrytý. Spolu 40 rôznych typov, takmer po každom stlačení klávesy.. Dosť výkonnejšie a rýchlejšie ako to robí fireDAC. Len to vedieť využiť. V tých typoch som lokálne narazil. Zatiaľ jediná vec, čo ma ozaj zradila.
E.
Pre môj prípad nemenné požiadavky kladené na databázovú enginu:
Excel kompatibilné funkcie (zabezpečím sám), očakávané typy polí a ich neobmedzené názvy.
Stačí, keď engina bude robiť, čo sľubuje. Čo sa dá od nej oprávnene predpokladať.
A áno, užívatelia v Exceli vyrobia tabuľky s tými najnemožnejšími názvami polí.
Veru ešte aj iné veci. Lenže na báze excelu stále pracujú stovky firiem, vrátane IT gigantov.
Nestačí sa len rozhorčiť, čo všetko by nemali robiť. To nezmeníme. Oni zamestnávajú stovky, ba tisíce študentov, ktorí riešia aj 12 hodinové úlohy formou Copy/Paste.

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 3120
  • Karma: 30
    • Verze Delphi: XE7 professional
Som amatér, ale jednu poznámku skúsim
Citace
A áno, užívatelia v Exceli vyrobia tabuľky s tými najnemožnejšími názvami polí. Veru ešte aj iné veci.
Ako som čítal Tvoj príspevok, tak pre Teba nemôže byť problém vyrobiť si nejakú funkciu na prevod názvov polí v Excel-y na korektné názvy pre DB.
Citace
Nestačí sa len rozhorčiť, čo všetko by nemali robiť. To nezmeníme. Oni zamestnávajú stovky, ba tisíce študentov, ktorí riešia aj 12 hodinové úlohy formou Copy/Paste.
Žiaľ zostáva len súhlasiť.

K bodu A len taká poznámka: tak to s tými vedúcimi pracovníkmi (vyhlásil som osobný boj anglickým výrazom v slovenčine, ak máme zodpovedajúce výrazy :) ) a inými absolventmi VŠ v praxi aj vyzerá.
« Poslední změna: 22-11-2017, 22:18:23 od Stanislav Hruška »
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Offline Miroslav Baláž

  • Plnoletý
  • ***
  • Příspěvků: 124
  • Karma: 4
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
7 GB dát mesačne sa zdá byť závažné, ale je to trochu inak.
Ide len o kontrolu určitých vybraných výkonov nad podriadenou firmou.
Tu sa jedná iba o kópiou živých dát.
Údaje sú dodávané v tisíckách text súborov.
Zásadné operácie a hospodárenie však nad nimi vykonáva niekto úplne iný.
Predtým riešené v Exceli. Limit 1 000 000 riadkov bol dosiahnutý cca za 6 dní.
Teraz zvládneme rok..

Online Delfin

  • Guru
  • *****
  • Příspěvků: 610
  • Karma: 27
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
Budiz, opustme co je a neni spravne a vratme se k tematu. Cilem je tedy simulace Access pro SQLite DBMS (se zachovanim SQL syntaxe Access, vcetne funkci)?

Jinak, pokud jde jen o presun dat, zvazil bych pouziti TFDBatchMove. Ma moznost mapovani sloupcu i datovych typu, a vytvorit v cilove DBMS rozumne schema (bez nudnych pohadek v nazvech objektu) by snad stalo v tomto pripade za uvahu. Porad si ale nejak nemuzu zaradit, co maji ty funkce spolecneho s "Tu sa jedná iba o kópiou živých dát." :-[
« Poslední změna: 23-11-2017, 00:44:45 od Delfin »
I'm a soldier, so don't panic!

Offline Miroslav Baláž

  • Plnoletý
  • ***
  • Příspěvků: 124
  • Karma: 4
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
Ad Stano:
Vážim si Tvoje odpovede, iba vychádzam z daných okrajových podmienok. To neznamená, že práve také predstavujú môj pohľad na ideálne riešenie databázy. Tiež mám nejaký ten zdravý úsudok. Iba pracujem v rámci mantinelov.

Ad Delfin:
1.
Táto citácia vyzerá nádejne, preskúmam:
Ohledne vlastnich funkci, staci(lo) dropnout komponentu TFDSQLiteFunction, prilinkovat driver, nastavit Name a ArgumentsCount, komponentu aktivovat a v OnCalculate handleru pristupovat k AInputs.Inputs a AOutput pomoci patricnych As<T> accessoru, napr:
2.
Jinak, pokud jde o presun dat, zvazil bych pouziti TFDBatchMove. Ma moznost mapovani sloupcu i datovych typu, a vytvorit rozumne schema (bez pohadek) by snad stalo v tomto pripade za uvahu. Porad si ale nejak nemuzu zaradit, co maji ty funkce spolecneho s "Tu sa jedná iba o kópiou živých dát." :-[
Získam na USB mesačne 6000 malých CSV a jeden veľký.  Asi tak pol na pol. Tie malé zlučujem do jednoho csv.
Nakoniec mám dva zdrojové CSV, cca po 3+ Giga. Nie som inak správcom dát. Nemám žiadny vplyv na prípadné havárie zdrojového systému. Ani neviem, čo sa v zdrojovom podniku s dátami rieši. Pracujem pre kontrolujúci podnik.
Mnou hore popísané riešenie, v originál maile, bod 10, (ohľadne rýchlosti) z CSV do SQLite trvá tušim 5 minút. Je to od testov nejaký ten mesiac, ale myslím, to určite nebolo viac. Takže spokojnosť s rýchlosťou importu až nad mieru. Dokonca sa bude dať asi ešte zlepšiť.. Taká rýchlosť sa asi nijak nebude dať prekonať. Ale ani nie je treba.
Samozrejme TFDBatchMove mám v merku. Na iné účely určite neraz použijem.
Uvedené CSV data majú svoje názvy polí od profi firmy, takže názvy sú "db korektné".
Kompatibilitu s Excelom naopak riešim v inej kategórii, v tej čo je pre študentov.
Ale aj pre svoj nástroj ako taký, chcem s MS Access kompatibilné funkcie. Na to som za roky zvyknutý.

Uff, toto som prehnal v mojom predošlom maile, opravujem:
Napríklad Format. Aby vyhovela tej z Accessu, dalo to dosť práce. U nej napríklad záleží na na type vstupných údajov. Access to zvláda komplexne (napríklad aj mimo mesiacov z rozashu 1..12, ale to nie je všetko).
Mesiace ( aj dni ), mimo bežný rozsah, zvláda fn DateSerial, nie Format.
Inak je citovaný výraz pravdivý

Offline Miroslav Baláž

  • Plnoletý
  • ***
  • Příspěvků: 124
  • Karma: 4
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
Delphin ďakujem aj za "náhradný" link na DocWiki
P.S. docwiki si muzes pro Berlin prohlizet na http://web.archive.org.
Je to trochu zložitejšie vnútri pri klikaní na linky, ale ako náhradné riešenie super.

Online Delfin

  • Guru
  • *****
  • Příspěvků: 610
  • Karma: 27
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
Získam na USB mesačne 6000 malých CSV a jeden veľký.  Asi tak pol na pol. Tie malé zlučujem do jednoho csv.
Nakoniec mám dva zdrojové CSV, cca po 3+ Giga. Nie som inak správcom dát. Nemám žiadny vplyv na prípadné havárie zdrojového systému. Ani neviem, čo sa v zdrojovom podniku s dátami rieši. Pracujem pre kontrolujúci podnik.
Mnou hore popísané riešenie, v originál maile, bod 10, (ohľadne rýchlosti) z CSV do SQLite trvá tušim 5 minút. Je to od testov nejaký ten mesiac, ale myslím, to určite nebolo viac. Takže spokojnosť s rýchlosťou importu až nad mieru.

A to jeste vypada, ze jsi nepouzil nativni, ale emulovany rezim array DML :)

Pokud jde jen o import dat do jine databaze, vyhral za me TFDBatchMove. Interne pouziva taktez array DML techniku a pomerne jednoduse umoznuje konfiguraci zdrojovych-cilovych sloupcu a mapovani datovych typu, stejne tak zvlada konverze typu (da se pripadne napsat manualni konverze). Zdroje a cile jsou pak dataset, SQL i textove soubory; tedy vcetne CSV (staci si jako zdroj patricne nakonfigurovat TFDBatchMoveTextReader).

Pro takovy pripad bych si vytvoril "mapovaci" utilitu (se sablonami mapovani pro firmy i jednotlive studenty) a nechal TFDBatchMove zaridit zbytek. Minimum prace a pri rozdeleni zdroju CSV napr. do adresaru moznost automatizace (s tim ze by zdroje pouzivaly stale stejne pojmenovani sloupcu i datovych typu). Pak uz by zbyl jen krok k tomu abys vytvoril sluzbu ktera bude cekat na notifikace zmen v adresarich a data automaticky exportovat do cizi databaze, samozrejme pokud bude souhlasit nastavene mapovani (na ty notifikace zmen existovala pekne napsana trida TDirectoryWatch).
« Poslední změna: 23-11-2017, 01:47:26 od Delfin »
I'm a soldier, so don't panic!

Offline Miroslav Baláž

  • Plnoletý
  • ***
  • Příspěvků: 124
  • Karma: 4
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
Stano, ešte k Tvojej odpovedi a návodu Access 2007. Dĺžka 64 znakov je dostatočná. Ale všimni si na priloženom obrázku, použitie ľubovoľného textu v názve poľa a aj v údajoch
Citace
9. Access a SQLite ako jediné rozumné DB, ak vynechám C/S, prakticky nemajú limitované názvy stĺpcov a tabuliek.. Dokonca sa dajú použiť aj znaky nad 255, zrejme aj Unicode. Tu ide o kompatibilitu s Excelom..
Pri Access-e si nie som o tom celkom istý. Takže help pre 2007
Citace
Názvy polí môžu pozostávať z čísiel a písmen v maximálnej dĺžke 64 znakov vrátane medzier.
Access engina už roky dovolí čarovať z názvami polí v zmysle tohoto obrázku:


 

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

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