SQLite BUG ?: SELECT Alias FROM ( Select Field1 Alias::<T> FROM Table)

[miroB]

Toto funguje (vráti pole x) :

Kód: MySQL [Vybrat]

1. SELECT * FROM ( select datum AS [x::DATE] from demo )

Príkaz v zmysle predošlého, s istotou obsahuje pole x, takže by nemal byť problém, ale skončí s chybou:
[FireDAC].[Phys].[SQLite] ERROR: no such column: x

Kód: MySQL [Vybrat]

1. SELECT x FROM ( select datum AS [x::DATE] from demo )

Test projekt je priložený

[miroB]

Tak som to skusil cez Create View
A veru nejde ani to.
Ospravedlnujem sa, ze je tam kdesi vidiet kod mysql. To je len formatovaci oznam.
Pracujem v SQLite

Kód: MySQL [Vybrat]

1. DROP TABLE if exists [demo];
2. CREATE TABLE if not exists [demo] ( id Integer, name TEXT( 20 ), Datum DateTime );
3. INSERT INTO [demo] ( id, name, Datum ) VALUES ( 1, ''Skúška'', GETDATE() );
4. CREATE VIEW if not exists AliasT AS select id, datum AS [x::DATE] from demo;

ale ani takto to nefunguje:

Kód: MySQL [Vybrat]

1. SELECT x FROM AliasT

ani takto to nefunguje (A to by snad uz malo fungovat. Alebo ?):

Kód: MySQL [Vybrat]

1. SELECT [x] FROM AliasT

toto tusim vypisuje iba string x :

Kód: MySQL [Vybrat]

1. SELECT "x" FROM AliasT

Pritom toto ide a pole x tam je..

Kód: MySQL [Vybrat]

1. SELECT * FROM AliasT

Mam to overene aj cez

Kód: Delphi [Vybrat]

1. FDQuery1.Fields[ 1 ].FieldName

Delfin sorry, ale Tvoj navrh mi vypise iba "x", miesto datumu.
Mam skusenost so zapisom:

Kód: MySQL [Vybrat]

1. SELECT [x] FROM table

Ale aj v tomto pripade hlasi chybu.
Horsi je ten SELECT VIEW, co je hore. Ten by teda veru ist mal..

Pouzij uvozovky, jde o alias:

Kód: MySQL [Vybrat]

1. SELECT "x" FROM ( select datum AS [x::DATE] from demo )

Kód: MySQL [Vybrat]

1. SELECT "uvozovky jsou treba, protoze pro alias lze napsat i kratkou pohadku" FROM ( select datum AS [uvozovky jsou treba, protoze pro alias lze napsat i kratkou pohadku::DATE] from demo )

[miroB]

Aha, tomu rozumiem, co pises.
Ale v zasade myslim, ze ide o chybu.
Vid aj
CREATE VIEW v predoslom prispevku a
CREATE TEMPORARY TABLE v tomto prispevku nizsie.
Pretoze, ako uzivatel, chcem aby veci fungovali ocakavane.
Ked autori ponuknu riesenie, nemaju skoncit v polovici (myslim autorov FireDAC)
Bohuzial vsetky veci okolo funkcii, ktore nevracaju typ, ale tvaria sa, ze by to malo nejako ist, je dost komplikovane. Dnes som to hodne studoval, robil testy, ved asi vies. Nemam teraz este kompletne informacie. Pokracujem v testoch. Vratim sa k tomu, az budem mat jasnejsie.
Inak aspon cez to create view, by clovek cakal, ze s typmi nejako lepsie vysporiadaju.
CREATE VIEW vrati spravny typ, ale nevie v SQL menom zavolat to predmetne alias::<T> pole.
Da sa otvorit len pomocou *    (v zmysle vsetky polia)
Vid moj predosly prispevok

Inak test CREATE TEMPORARY TABLE dopadol  presne s rovnako nepriaznivym vysledkom, ako CREATE VIEW.
Pole vytvorene metodou alias::<T> nie je mozne nasledne v selecte zavolat.
Znovu len ako
SELECT * FROM myTempTable

[miroB]

Kód: MySQL [Vybrat]

1. DROP TABLE if exists [demo];
2. CREATE TABLE if not exists [demo] ( id Integer, txtTest TEXT( 20 ), Datum DateTime;
3. INSERT INTO [demo] ( id, txtTest, Datum ) VALUES ( 1, ''Skúška'', GETDATE() )
4. CREATE TEMPORARY TABLE tempTbl AS select id, txtTest AS [myText::Text(20)], datum AS [myDateTime::DATE] from demo

Veru Delfin mas pravdu, ide to zavolat len takto:

Kód: Delphi [Vybrat]

1. SELECT id, [myText::Text(20)], [myDateTime::DATE] FROM tempTbl

Cakal by som ze nazvy stlpcov v tomto pripade skratia o to "::<T>"
Moc by to pomohlo.
Snad si to spravim sam.
Ale potom aku mam istotu, ze tam niekde dalej, nie je milion inych chytakov?

Davam este na povsimnutie tento zadrhel:
Ako vidiet tabulka obsahuje aj pole typu text :  txtTest Text(20)
Po ulozeni do Temporary table sa vsak pole zmeni na Text(32000), nejak tak, plus minus.
Takze aj tam, kde nie je pole vypocitane, ale dalo by sa prevziat z povodnej struktury tabulky sa stane text neznamej dlzky. A neda sa zobrazit  v gride. No viem da sa to naprogramovat. Ale na toto veru nie som z Access enginy celkom zvyknuty. Tam to je dost hladsie..
Takze aj s textom nastavaju presne tie neiste hratky, ako je to u datumov.. Grrr..

[miroB]

No a uplne vtipne je toto zistenie:
SELECT z CREATE VIEW, presnejsie tento:

Kód: MySQL [Vybrat]

1. SELECT * FROM AliasT

v tomto prikaz v Delphi kode:

Kód: Delphi [Vybrat]

1. s := FDQuery1.Fields[ 1 ].FieldName

naplni do premennej s, hodnotu x
Ale SELECT tam tu hodnotu nevidi!
Ten vidi skutocny, dlhy nazov pola v tabulke:
[x::DATE]
Tak to povazujem za ozaj dost zlomyselne od autorov.

Chapem, ako je to technicky. Ozaj tak, ako pise Delfin, ale nechapem, ako moze programator (autori FireDAC) ponukat taketo riesenie.
Z pohladu na jednu a tu istu vec, by som mal ako z SQL, tak na druhej strane z pohladu v Delphi

Kód: Delphi [Vybrat]

1. FDQuery1.Fields[ 1 ]

ziskat tem isty vysledok.
Ale nie: raz je to
[x::DATE]
a druhy raz iba
x

Uff mozno to je technicko-abstraktne-logicky v poriadku, lenze sme skor ludia nez stroje.
Potom jasne, ze IT oddelenie sa len tazko moze dohodnut s marketingom.
Ked jedni ziju v praktickom a druhi v abstraktnom svete.
Ti jedni maju realne peniaze a ti druhi skor abstrakne:)

[miroB]

Ano bonus FireDAC to je.
Lenze a la Microsoft (Gates), nie a la Apple (Jobs) 

[miroB]

No, ak by sme sa pozreli hlbsie na FireDAC a jeho parsovanie SQL, tak by sme tam nasli take veci, ze hlada zatvorku v obecnom poli "vyraz AS xy::Date", kde vyraz moze byt hocico napriklad toto:

Kód: MySQL [Vybrat]

1. "ja som text so zatvorkou (, prave bola, ukoncenie)" || GetDATE() || " a este ( dalsie ) zatvorky tu mozu byt" AS mojText::Text(32)

No a ktoru zatvorku asi najde prvu?
Je tam jesne pouzite

Kód: Delphi [Vybrat]

1. ..Pos( '(', text ) ..

To mi pripada hodne dobrodruzne parsovanie. To riesenie, co ponukaju je z mojho pohladu dost alibisticke.
Potrebujem SQL realne vyuzit. Pomerne v obecnej rovine. A tam veru narazam na necakane mantinely u toho FireDAC riesenia.
Ano v teoretickej rovine je vsetko ako vravis. Lenze rad by som ziskal vysledky. A zacinam narazat na znacne prakticke problemy, kde moznosti FireDAC v tomto pripade nevedu k rieseniu.
Mam rozpracovany Tvoj i svoj navrh riesenia prenosu informacie zo vzorca do vysledku, ale zatial som nedosiahol ziadne uspokojive a jasne vysledky.
Nieze by to neslo. Ono to ide podla planu, ale ani to nestaci pre dokoncenie praktickej myslienky. Zatial.. Budem sa snazit dalej..

[miroB]

Porad si muzes parsovat prikazy sam. A pro resultset si pred otevrenim sestavit kolekci perzistentnich poli. A ty datove hinty, pokud bys je potreboval pouzit z prikazu odstranovat. Verim ze lexeru pro SQLite budou mraky (mozna i pro Delphi)

Dobre, ak by som išiel touto cestou. Teda nejaký low-level API. Myslím toto:
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Using_SQLite_with_FireDAC#Using_SQLite_low-level_API
tak ako budem prezentovať dáta? Napríklad do dbGrid.
Môžeš mi naznačiť ako ďalej pokračovať, keď by som to riešil napr. takto:
^{(vybraté z uvedeného dokazu)}

Kód: Delphi [Vybrat]

1.     oStmt := TSQLiteStatement.Create(oDB);
2.     try     // prepare statement
3.       oStmt.Prepare('select * from "Orders" where OrderID > :ID1 and OrderID < :ID2');
4.              // add bind variables (parameters)
5.       for i := 1 to oStmt.ParamDefsCount do
6.         TSQLiteBind.Create(oStmt.Params);
7.              // add column variables (fields)
8.       for i := 1 to oStmt.ColumnDefsCount do
9.         TSQLiteColumn.Create(oStmt.Columns).Index := i - 1;
10.              // set parameter values and execute
11.       oStmt.Params[0].AsInteger := 11000;
12.       oStmt.Params[1].AsInteger := 12000;
13.       oStmt.Execute;
14.              // fetch records and read columns
15.       while oStmt.Fetch do
16.         Memo1.Lines.Add(Format('OrderID: %d, CustomerID: %s',
17.           [oStmt.Columns[0].AsInteger, oStmt.Columns[1].AsString]));
18.     finally
19.       oStmt.Free;
20.     end;

ako nasypem údaje do nejakého dataSetu namiesto toho Memo1, čo je použité vyššie?
Ak sa tu niekto podelí so skúsenosťami s uvedenej oblasti, bol by som veľmi vďačný.
Poznatky, upozornenia, zdroje, vzory kódov, výstrahy, čokoľvek.
Pre získanie predstavy, či by bola schodná táto cesta.
Takže vopred ďakujem:)

[miroB]

Hura, jeden existujuci priklad vyuzitia TSQLiteStatement, som nasiel na disku:)
FireDAC.Phys.SQLiteIniFile.pas v ceste:

Kód: Delphi [Vybrat]

1. Database\FireDAC\Samples\AddOn\SQLiteIniFile\

Je tam funkcne demo.
Ale inak bieda, ziadna dalsia slusna dokumentacia, ci priklady. Ani googlenie nepomohlo.

[miroB]

Ahoj delfin,
nakoniec som postnul tuto zakladnu temu aj na forum Embarcadero.
https://forums.embarcadero.com/thread.jspa?threadID=269003
Moja angličtina môže byť nezrozumiteľná, ale je tam jasný funkčný príklad.
Ten dávam aj sem.
V skratke: tvrdím, že alias::<T>, OK.
Lenže očakávam od neho len ten typecast výsledku, ale určite nie rozšírený názov poľa.
Predstav si viac vnorených SELECT príkazov. Čo s tým strašným chaosom, ktorý by tak vznikol veľmi rýchlo?
Že to nikoho nezaujíma? Ale malo by. Potom by sa tá celá engina používala omnoho produktívnejšie.
Takto sa to používa málo. A je to ozaj problém.
Hmm, teraz ma napadlo, že keby fungovala poriadne funkcia CAST, tak by som mohol dať normálny Alias a nie ten technokratický
Lenže funkcia CAST sa chová ako všetky funkcie vo FireDAC/SQLite. Že nevracia správny typ, ale len ten základný. Takže v SQLite asi ani nemá moc nejaký význam..

Veď aj FireDAC nakoniec interne priznáva, že meno výsledného poľa v skutočnosti nie je to rozšírené, ale to, čo je pred ::<T>
Mám na mysli Field_x_.FieldName
Tak uvidíme, či tam niekto ponúkne riešenie.

[pf1957]

nakoniec som postnul tuto zakladnu temu aj na forum Embarcadero.

Sice jsou cross posty neeticke, ale ja na tvem miste bych to postnul radeji SO - prece jenom tam to auditorium je asi nejvetsi a autor FireDac pred lety sam diskutovaval...

[miroB]

nakoniec som postnul tuto zakladnu temu aj na forum Embarcadero.

Sice jsou cross posty neeticke, ale ja na tvem miste bych to postnul radeji SO - prece jenom tam to auditorium je asi nejvetsi a autor FireDac pred lety sam diskutovaval...

Dik, skusím aj to asi.

[miroB]

Delfin, tak ja neviem, nejak tusim, ze mas pravdu. Ale nechcem sa s tym celkom zmierit, pretoze to jednoducho potrebujem.
Ked veci potrebujem, tak sa moc nestaram, ze by nemali ist. Spravim vsetko pre to, aby isli, aby isli lepsie, tak ako potrebujem. Nech maju nejaky zmysel. Spravidla to rovnako potrebuju aj ostatni. Iba sa nikto neozve.
V tom SQLite/FireDAC je uz tak vela spraveneho a zrazu, bac.
Na jednom promile sa ma zastavit cele kvalitne riesnie?
Tak som to postnul na SO. Znacne som to upravil, takze sa to na prvy pohlad moc nepodoba. Muselo sa to zaobist bez vzoroveho kodu ale nastrkal som tam toho dost. Mozno sa toho niekto uchopi.
Mozno to zmazu, je to jedno. Mam ine starosti nez aby som sa obzeral, ako dopadne hodnotenie:)
Tu je link:
https://stackoverflow.com/questions/47517284/firedac-sqlite-typecast-with-as-fldtype-in-nested-queries-functions-how-t

[miroB]

Fajn ze se nevzdavas Jen mam vazne obavu ze toho moc nevyresis. Muzes jeste jit cestou toho parsovani a hinty z vnitrnich SELECT listu u SQL prikazu pred spustenim vyhazet. U definice VIEW asi holt smula; tam by musel SQLite nejako podporovat definici nazvu a datovych typu.

Staci si jen predstavit co se deje na ktere strane. V tomto pripade se prikazy spousti na SQLite engine, a produktem uspesneho spusteni je popis datasetu ze ktereho muze FireDAC pomoci datovych hintu specifikovat pole v kolekci "na prani".

Aha, tak to znamená, že "fld::type" sa musí strčiť celé do SQLite enginy, aby sa zas až pri výstupe dal dešifrovať typ pre prezentáciu dát?
No a mimochdom UDF funkcie nie su tie prišité aj vrátane definície práve do enginy?
A nemôžu teda prenášať žiadnu informáciu, keď sú k engine nejak prilinkované?
Nechce sa mi veriť, že toto je neriešiteľný problém.
Voči tomu, čo je v oboch balíkoch už naprogramované.

[miroB]

To API neni pro prime pouziti. Nic Ti v jeho pouziti nebrani, jen se nediv chybejici dokumentaci. Tzv. "low level" je z pohledu FireDAC o vrstu vys (tam uz se sdruzuji podporovane DBMS).

Ale ja nepsal nic o low level API. Tohle muzes udelat i "zvenku". Pred predanim prikazu FireDAC objektu prikaz rozparsujes, poskladas si perzistentni pole, predas upraveny dotaz a ten spustis.

FireDAC spousteny prikaz upravuje jen v pripade pouziti maker, takze neni treba chodit tak hluboko do nitra

Na ktorom mieste presne v kode mozem povedat, ze nechcem column definition podla FireDAC, ale podla seba.
Ako nizko musim teda ist? Ak vravis., ze nie je uplne nutne low-level.
Niekde som videl aj take odporucene riesnie, ze si pred kazdym SQL vytvoris temp table so svojou definíciou polí a tam nasypeš data zo selectu.
No a ak by som to spojil s low-level, tak som pomaly doma..

[miroB]

Naplnis jen kolekci FieldDefs. Tak jako bys to udelal v design time pres fields editor.

Ak uvediem konkretne na priklade, tak kedy v ramci tohoto?

Kód: MySQL [Vybrat]

1.   FDQuery1.SQL.Text := 'SELECT * FROM [myView]';                  
2.   FDQuery1.Active   := True;

Pred riadkom 1, 2, alebo az na konci.
Zatial som to nikdy neriesil.
Design time pri databazach nepouzivam snad nikdy. Takze to mi tiez moc nehovori.

[miroB]

Naplnis jen kolekci FieldDefs. Tak jako bys to udelal v design time pres fields editor.

Ak uvediem konkretne na priklade, tak kedy v ramci tohoto?

Kód: MySQL [Vybrat]

1.   FDQuery1.SQL.Text := 'SELECT * FROM [myView]';                  
2.   FDQuery1.Active   := True;

Pred riadkom 1, 2, alebo az na konci.
Zatial som to nikdy neriesil.
Design time pri databazach nepouzivam snad nikdy. Takze to mi tiez moc nehovori.

iiha, to bolo jednoduche. Takze sa blizim k rieseniu.
Opravujem opravene
Bolo to jednoduche, ale unahlil som sa so svojim prispevkom, ten som zmazal a davam spravne zenenie kodu:

Kód: Delphi [Vybrat]

1. FDQuery1.SQL.Text := 'SELECT * FROM ( select [id], [datum] AS [myDate::DATE] from [demo] )';
2. FDQuery1.Active   := True;
3. i := FDQuery1.FieldDefs.Count; // 2
4. FDQuery1.FieldDefs.Clear;
5. i := FDQuery1.FieldDefs.Count; // 0
6. FDQuery1.FieldDefs.Add( 'id', ftSmallInt, 0 );
7. FDQuery1.FieldDefs.Add( 'datum', ftDate, 0 );
8. i := FDQuery1.FieldDefs.Count; // 2
9.  

Kod som doplnil do toho, co som publikoval na embarcadero. Takze keby niekto chcel vyskusat. Ma aj cely kod.
Len toto bolo "vylepsene", co je uvedene tuna som teda pozmenil

[miroB]

BUU.......
POZOR. IBA SA TVARI, ze ide. Vytvorim novu definiciu poli, aj vratane typu.
Zda sa, ze prebehne OK. Ale typ sa nepodari zmenit.
Testujem podrobnejsie a nejde to. Prispevok uz neviem zmazat, ale dam opravu, ked budem vediet, ako dalej pokracovat.

Naplnis jen kolekci FieldDefs. Tak jako bys to udelal v design time pres fields editor.

Ak uvediem konkretne na priklade, tak kedy v ramci tohoto?

Kód: MySQL [Vybrat]

1.   FDQuery1.SQL.Text := 'SELECT * FROM [myView]';                  
2.   FDQuery1.Active   := True;

Pred riadkom 1, 2, alebo az na konci.
Zatial som to nikdy neriesil.
Design time pri databazach nepouzivam snad nikdy. Takze to mi tiez moc nehovori.

iiha, to bolo jednoduche. Takze sa blizim k rieseniu.
Opravujem opravene
Bolo to jednoduche, ale unahlil som sa so svojim prispevkom, ten som zmazal a davam spravne zenenie kodu:

Kód: Delphi [Vybrat]

1. FDQuery1.SQL.Text := 'SELECT * FROM ( select [id], [datum] AS [myDate::DATE] from [demo] )';
2. FDQuery1.Active   := True;
3. i := FDQuery1.FieldDefs.Count; // 2
4. FDQuery1.FieldDefs.Clear;
5. i := FDQuery1.FieldDefs.Count; // 0
6. FDQuery1.FieldDefs.Add( 'id', ftSmallInt, 0 );
7. FDQuery1.FieldDefs.Add( 'datum', ftDate, 0 );
8. i := FDQuery1.FieldDefs.Count; // 2
9.  

Kod som doplnil do toho, co som publikoval na embarcadero. Takze keby niekto chcel vyskusat. Ma aj cely kod.
Len toto bolo "vylepsene", co je uvedene tuna som teda pozmenil

[miroB]

BUU.......
POZOR. IBA SA TVARI, ze ide. Vytvorim novu definiciu poli, aj vratane typu.
Zda sa, ze prebehne OK. Ale typ sa nepodari zmenit.

..
No, a pak jsem psal ze ty definice je treba vytvorit pred otevrenim kurzoru (v puvodnim kodu se kurzor otevira na radku 2.); tj. pred nastavenim Active na True (nebo volanim Open).

Nie typy poli v tomto pripade nejdu zmenit. Ani pred, ani po.
V rpípade pred, otvorenie FDQuery ich premaze. NEPOMOZE.
Ked su po, tak sa mozem hrat, ze ich prepisem, aj zmazem, a znovu vytvorim. To sa zda, ze ide. Aj pocet  v Count sa zmeni, ale po vytvoreni su tam zase tie typy, co predtym.

Ale hrajem sa s Low Level API: TSQLiteDatabase a TSQLiteStatement.
Tam viem ziskat udaje bez toho, ze by bol naplneny dataset.
Ten mozem slobodne sam vytvorit a naplnit ho.
Co mi odporucas, mam pouzit TFDMemTable, alebo by na to bolo nieco vhodnejsie?