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::DATETIME6. 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:
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):
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.
