Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Obecné / Re:Zvládnem to a ktorá DB?
« Poslední příspěvek od Slappy kdy Dnes v 05:46:44 »
Poviem Ti to na rovinu. Vykašli sa na to.
Ak Ti navrhli cenu za sw 100 - 150 EUR  a ako hlavný "server" plánujú použiť 10 ročný PC Celeron z druhej ruky za 80 EUR,
tak asi veľmi nemajú prehľad o trhu a absolútne ani šajn o problematike fungovania reštaurácie a evidencie ako takej.
Relatívne slušné vybavenie reštaurácie s mobilným čašníkom a funkčným skladom, rezerváciami, odloženými účtami, atď... - cena HW + SW začína na 3200 EUR +...

100% suhlas. Poziadavky sa casom aj tak zmenia. Predstavuju si to ako Hurvinek valku, ale po par pouzitiach uz budu sypat dalsie a dalsie poziadavky a ak ich budu chciet mat v tom istom budgete tak to uz budu uplne mimo.

Inak na trhu je kopec podobnych produktov, staci pohladat. Pripadne nejaku free/open source app a je to...
2
Obecné / Re:TDictionary do streamu/do súboru
« Poslední příspěvek od Delfin kdy Dnes v 02:20:11 »
Ďakujem toto mi pomohlo:
.. Co se tyce nebinarni serializace, nove Delphi s sebou prinasi minimalne JSON marshalling.
V zásade takto:
Kód: Delphi [Vybrat]
  1. s := TJson.ObjectToJsonString( pair.Value );
  2. writer.WriteString( s );
Ešte musím vyšpekulovať ako naspäť. Ale snáď to už pôjde.

Napr.:

Kód: Delphi [Vybrat]
  1. var
  2.   Category: TCategory;
  3. begin
  4.   Category := TJson.JsonToObject<TCategory>(s);
  5. end;

Jeste bych se zbavil toho TWriteru a pouzil nektery z TStream potomku.
3
Obecné / Re:TDictionary do streamu/do súboru
« Poslední příspěvek od mibainfo kdy Dnes v 01:36:04 »
Ďakujem toto mi pomohlo:
.. Co se tyce nebinarni serializace, nove Delphi s sebou prinasi minimalne JSON marshalling.
V zásade takto:
Kód: Delphi [Vybrat]
  1. s := TJson.ObjectToJsonString( pair.Value );
  2. writer.WriteString( s );
Ešte musím vyšpekulovať ako naspäť. Ale snáď to už pôjde.
4
Ostatní DB / SQLite a dátumy v tvare DateTime (FireDAC)
« Poslední příspěvek od mibainfo kdy Dnes v 01:24:29 »
V prípade dátumov typu DATETIME v SQLite+FireDAC, nastane menší problém pri použití takéhoto typu vo výraze.
(Ako reakcia na príspevky Stano Hruška a Delfin. Odkazy viď dolu.)
Majme tabuľku:
Kód: MySQL [Vybrat]
  1. CREATE TABLE if not exists [demo] ( Datum DateTime );
  2. INSERT INTO [demo] ( Datum ) VALUES ( GETDATE() );
Stĺpec definovaný v tabuľke ako DATETIME je v rámci SELECT prezentovaný očakávane. Prejaví sa správne aj vo výpise v dbGrid.
Akonáhle sa ale jedná o výraz, stratí sa informácia o rozšírenom type DATETIME
Miesto toho je typ zmenený na REAL/FLOAT. Teda na jeden zo základných typov SQLite.
Nie je možné použiť ani Accessor AsDateTime. Treba použiť Accessor Value, alebo AsFloat. Takto získanú hodnotu je ale možné rovno priradiť do premennej typu DateTime. K tomuto tvrdeniu viď príklad.
Kód: MySQL [Vybrat]
  1. SELECT Datum, Datum + 1 AS Zajtra FROM [demo]
Napríklad MS Access pre výraz Datum + 1 vráti samozrejme rovno správny typ dátum..
Podobne, keď sa vyrobí užívateľská funkcia, ktorá má vrátiť výsledok typu DateTime, pre SQLite vráti iba typ REAL.
Funkcia v SQLite nie je schopná vrátiť iný typ, než základný typ.
Preto nemá význam ani:
Kód: MySQL [Vybrat]
  1. CAST( Datum + 1 AS DATE )
Pre prípadné ďalsie uživateľské funkcie, ktoré by boli závislé na vstupe typu DATETIME alebo REAL (overload), teda nie je šanca.
Vyššie uvedené fakty sa samozrejme premietnu aj do výpisu v dbgride, kde výrazy nad typom dátum už nie sú dátum, ale float.
Ale to všetko sa dá obísť. Napríklad takto:
Kód: MySQL [Vybrat]
  1. Datum + 1 AS [xy::DATETIME]
Negatívom tohoto riešenia je, že TypeCast sa síce vykoná správne, ale pole sa nevolá xy, ako by sa dalo čakať, ale takto: 'xy::DATETIME' !!!
Takže sme vlastne stratili možnosť použitia nejakého prijateľného aliasu pre stĺpec.
Ešte horšie je, že Delphi sa interne tvári, že názov stĺpca je xy, rovnako aj vo výpise v dbGrid. Lenže interne je stĺpec označený aj s dvojbodkou a typom. Takže prípadný ďalší SELECT musí obsahovať komplet názov.

Pozitívne je, že všetky operácie nad dátumom, či double sa samozrejme stále vykonávajú správne.
Pretože DATETIME je skutočne double. Len chýba tá rozšírená info, pre výpisy a prípadné funkcie.
Tie "drobné" úpravy zostávajú teda na užívateľovi.

Teoretickým východiskom pre výpis do dbGrid, je napríklad vytvorenie dočasnej tabuľky so štruktúrou, kde sa vhodne nahradí REAL za DATETIME. Keď sa do takejto tabuľky nasype výsledok výrazu s dátumom v rámci SELECT, tak potom pri SELECT-e z tejto tabuľky bude zobrazenie dátumov v poriadku.

Dátum v tvare DATETIME je kompatibilný s MS Access, Delphi a s Excelom, resp. aj s Variant typu varDate.

Tento príspevok je reakciou na :
.. SQLite som raz skúšal, ale veľmi rýchlo som pohorel na dátumoch. Nestojí mi to zato. ..
a na:
Stano, myslim, ze datumy v SQLite nie su az taky problem.
Staci prepnut v Connection na datum typu DateTime a si ako v Delphi.

O zadnem problemu s datumy nevim. Co nastavujes v connection definition parametru DateTimeFormat je jen zpusob jakym se budou data do databaze ukladat. Accessorem AsDate(Time) zapisujes do parametru a ctes z poli Delphi typ TDate(Time) a je jedno jak jsou data o vrstvu niz ulozena. Kdyztak ho zkuste popsat v samostatnem vlakne nebo poslete odkaz na existujici... ;)
5
Obecné / Re:Zvládnem to a ktorá DB?
« Poslední příspěvek od vandrovnik kdy 12-12-2017, 22:41:06 »
Jak už tady zaznělo, takováhle zadání mívají tendenci se rozrůstat.
- my potřebujeme vidět, co jsme odeslali teď / před chvílí / u stolu 22
- my to už odeslané potřebujeme opravit
- my těch položek máme hodně a potřebujeme se v nich nějak rychle pohybovat...
Takže pokud za 150, tak bych doporučoval hodně přesně vyspecifikovat, co ta app bude dělat, a že rozhodně nebude dělat nic navíc :-)
6
Obecné / Re:Zvládnem to a ktorá DB?
« Poslední příspěvek od Stanislav Hruška kdy 12-12-2017, 22:32:02 »
Citace
Nebo kam bys chtel ukladat data treba v pripade dlouhodobeho vypadku wi-fi?
Až tak ďaleko som sa v úvahe nedostal ??? Pre mňa veľmi dobrá pripomienka. Na to postačí aj Access.
To ma privádza na myšlienku, že by sa ráno na klientov nahral jedálny lístok a údaje na server by sa poslali na konci zmeny. V takom prípade by ma spojenie so serverom netrápilo. Po každom prenesení údajov na server by sa DB na klientovi vyčistila. Hm, ale je tam ešte požiadavka na kontrolu počtu vydaných a pripravených jedál. A to bez pripojenia tabletov na server nebude aktuálne.

K dátumom. Nechce sa mi teraz hľadať tú diskusiu. Dostal som odpoveď, že dátumy sú taká menšia alchýmia. Možno si to pamätáš.
7
Obecné / Re:Zvládnem to a ktorá DB?
« Poslední příspěvek od Delfin kdy 12-12-2017, 22:19:47 »
Citace
Pocitam, ze vsetky tazkosti okolo datetime a SQLite sa daju vyriesit.
Samozrejme, že sa dajú. Ale ako mi jeden tu odporúčal. Prečo riešiť niečo čo nemusíš. Ostaň pri FB. Dal som aj dávam mu za pravdu.

O zadnych tezkostech s SQLite datumy nevim a to FireDAC znam dost dlouho. Ja mel na mysli SQLite na strane klienta. Nebo kam bys chtel ukladat data treba v pripade dlouhodobeho vypadku wi-fi? Mam na mysli Androidi tablet... Nikdy by me nenapadlo doporucovat pro serverovou aplikaci SQLite ::)

Vraj to je práca na jednu dve hodiny :D . To som napísal, aby mal objednávateľ aspoň hrubú predstavu čo vlastne chce >:( Myslím si, že to číslo o dosť vyššie.

Zadani mas dane, ni? Evidovat objednavky a v urcitou dobu ukazat jejich pocet. Nic vic. Za 150 mi takova uloha prijde fer :)
8
Obecné / Re:Zvládnem to a ktorá DB?
« Poslední příspěvek od Stanislav Hruška kdy 12-12-2017, 22:12:06 »
Citace
Pocitam, ze vsetky tazkosti okolo datetime a SQLite sa daju vyriesit.
Samozrejme, že sa dajú. Ale ako mi jeden tu odporúčal. Prečo riešiť niečo čo nemusíš. Ostaň pri FB. Dal som aj dávam mu za pravdu.
Citace
Ja bych to udelal jako webovou aplikaci: v tabletu bezi jen browser pripojeny k serveru.
Ja o tom nemám ani páru. Stálo by mi to zato študovať celú tú problematiku? Hlavne keď si spomeniem na rôzne problémy s tým spojené čo sa tu už riešili.
Citace
V tom popise máš asi 0,5 % problematiky, ktorú budeš musieť riešiť.
Vraj to je práca na jednu dve hodiny :D . To som napísal, aby mal objednávateľ aspoň hrubú predstavu čo vlastne chce >:( Myslím si, že to číslo o dosť vyššie.
9
Obecné / Re:Zvládnem to a ktorá DB?
« Poslední příspěvek od Delfin kdy 12-12-2017, 21:55:57 »
Stano, myslim, ze datumy v SQLite nie su az taky problem.
Staci prepnut v Connection na datum typu DateTime a si ako v Delphi.

O zadnem problemu s datumy nevim. Co nastavujes v connection definition parametru DateTimeFormat je jen zpusob jakym se budou data do databaze ukladat. Accessorem AsDate(Time) zapisujes do parametru a ctes z poli Delphi typ TDate(Time) a je jedno jak jsou data o vrstvu niz ulozena. Kdyztak ho zkuste popsat v samostatnem vlakne nebo poslete odkaz na existujici... ;)
10
Obecné / Re:Zvládnem to a ktorá DB?
« Poslední příspěvek od mibainfo kdy 12-12-2017, 21:43:24 »
Stano, myslim, ze datumy v SQLite nie su az taky problem.
Staci prepnut v Connection na datum typu DateTime a si ako v Delphi.
Je fakt, ze ked spravis SELECT, tak datum prestane byt datum a premeni sa na double.
Vtip je v tom, ze operacie nad datumom sa vo forme double samozrejme vykonavaju spravne.
Pretoze datum je skutocne double.
Iba chyba informacia o tom. Preto si to uzivatel musi strazit.
Nie je problem spravit par sikovnych funkcii, ktore prevedu real na string pre potreby zobrazenia datumov a casu. Vid Delphi funkcia FormatDateTime.
No a matemat. operacie nad datumom/casom funguju ocakavane.
Cisla pred desatinnou bodkou znamenaju pocet dni od 1.1. 1900, cisla za desatinnou bodkou su zlomky dna.
Mam funkciu CDate  (napodobenina tej z MS Access), ktora prevadza double na datum, bohuzial je nutny nemaly zasah do zdrojoveho kodu FireDAC, pretoze funkcie nevracaju typ dat taky ako ponuka firedac, ale len taky, ako su zakladne typy SQLite.
Ale teoretickym vychodiskom je vytvorenie docasnej tabulky so stukturou, kde je vsetko povodne, len polia typu datum (pre SQLite je to real/doble), sa zadefinuju ako datetime.
Ked sa do tabulky s takto upravenou nasype vysledok zo SELECT, tak potom je to uplne rovnake, ako by si pracoval s datumami v MS Access a tie su kompatibilne s Delphi a s Excelom.
Alebo aj variant varDate. Samozrejme to netreba riesit pocas vypoctov, ale az v zaverecnom/vyslednom SQL.
Pocitam, ze vsetky tazkosti okolo datetime a SQLite sa daju vyriesit.
Popravde toto podrobne vyskumam pocas nejakeho toho mesiaca.., ale neocakavam zasadne problemy.
Stran: [1] 2 3 ... 10