602SQL Server a formát datumu

Petr Poláček

602SQL Server a formát datumu
« kdy: 27. 03. 2014, 19:42:48 »
Vím, že je to už hodně staré téma a vůbec netuším, zda se ještě někdo 602sql serverem zabývá. Chtěl jsem si pohrát s 602SQL 8.1 a ve volném čase jej ze zvědavosti použít pro docházkový systém Docházka 3000. Ten už se podařilo zprovoznit na mysql, postgresql, ms sql 2008 i 12, oracle 11 a firebirdu. Tak proč netestnout 602sql, když je to český produkt. Ale narazil jsem na problém, na který jsem v dokumentaci nenašel odpověď. Docházka používá pro datumové položky formát yyyy-mm-dd. Tedy potřebuji do položek typu date a datetime (či timestamp) dostat datum v tomto formátu. Ale 602sql snad podporuje jen dd.mm.yyyy a nikde jsme nenašel možnost, jak vytvořit třeba vlastní datový typ nebo funkci, která by vzala i yyyy-mm-dd. Netušíte někdo, jak to v 602sql serveru 8.1 udělat?
« Poslední změna: 28. 03. 2014, 11:27:19 od Petr Krčmář »


Re:602sql server a formát datumu
« Odpověď #1 kdy: 27. 03. 2014, 19:56:12 »
SQL databáze mají zpravidla pro datum vlastní datový typ. Konverzi na ten datový typ provádí buď knihovna pro práci s databází (např. JDBC driver - předáte mu java.util.Date a driver to převede na interní databázový typ pro datum), nebo na to má databáze funkce, které umí datum zadaný jako text převést na interní typ pro datum, případně tu konverzi databáze provádí automaticky. Pak bývá konfigurovatelné, v jakém formátu ta automatická konverze očekává vstup.

Takže záleží na tom, co ten váš software používá. Pokud datum uvádí rovnou jako text v SQL dotazech, je to ten nejhorší způsob použití a přímá cesta k SQL injection. Vy byste v takovém případě musel nakonfigurovat automatickou konverzi, aby používala tenhle formát.

Petr Poláček

Re:602sql server a formát datumu
« Odpověď #2 kdy: 28. 03. 2014, 08:25:16 »
Díky za informace. Program ty datumy sice zadává přímo do dotazů, ale ne bez kontroly. Vstup od uživatele (který je ve formátu dd.mm.rrrr) nejprve rozebere na rok, měsíc, den, převede na čísla a prožene php funkcí checkdate. Pokud neprojde, vrátí uživateli chybovou hlášku. Až když projde, tak to složí zpět, ale do rrrr-mm-dd a použije přímo v sql dotazu. Takže sql injection snad nehrozí.

Ale spíš by mne zajímalo, zda někdo někdy řešil (a vyřešil), jak v 602sql nastavit typ datumových položek na rrrr-mm-dd. Procházel jsem dokumentaci, ale nenašel jsem pro to ani převodní funkci na straně sql serveru, ani nějakou proměnnou prostředí či něco podobného. Přeprogramovávat do přímo v docházce nemůžu, takže jsem potřeboval, aby to bylo možné nastavit na straně sql serveru místo jím používaného dd.mm.rrrr

Tomas Z.

Re:602sql server a formát datumu
« Odpověď #3 kdy: 28. 03. 2014, 08:48:03 »
Pomocí make_date a substring/strcopy by mělo být možné celkem triviálně napsat vlastní funkci.

Ale naposledy jsem to viděl před tak dvanácti lety, takže víc nenapovím.

Re:602sql server a formát datumu
« Odpověď #4 kdy: 28. 03. 2014, 08:51:45 »
Ale spíš by mne zajímalo, zda někdo někdy řešil (a vyřešil), jak v 602sql nastavit typ datumových položek na rrrr-mm-dd.
Jak už jsem psal, typ datových položek je datum. Vás ale zajímá konverze ne řetězec.

Procházel jsem dokumentaci, ale nenašel jsem pro to ani převodní funkci na straně sql serveru
Převodní funkce se jmenují Str2date a Date2str. Pomocí funkcí pro práci z řetězci si případně můžete formát upravit do podoby, jakou potřebujete.


Petr Poláček

Re:602SQL Server a formát datumu
« Odpověď #5 kdy: 31. 03. 2014, 08:50:04 »
Protože nemůžu upravovat kód programu, potřeboval bych spíš něco, co formát data jednou nastaví a pak už samotné sql dotazy nemusí být žádným způsobem upraveny.
Něco jak je v Oracle: set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'
nebo ve Firebirdu timestampformat="%Y-%m-%d %H:%M:%S"
Pak už program bez jakékoli úpravy samotných sql dotazů funguje.

Chci to jen kvůli porovnání rychlosti Docházky 3000 s různými SQL servery. Rozhodně to není pro běžné používání. Jen pro tento malý experiment. Zatím mám hotové testy pro MySQL 5.4, PostgreSQL 9.3, MS SQL 2008 i 12, Oracle 11g, Firebird 2.5 a SQLite. Když bude čas, tak mám ještě v plánu Informix a DB2. U 602SQL 8.1 jsem to zatím vyřešil brutálně tak jako v SQLite - místo datetime a date se prostě použil char.
Nakonec sem ho musel použít i místo typu time. Protože např. u dotazu select * from normy where zacatek>'04:00:00' vracel 602SQL server chybové hlášení, když byla položka zacatek typu time. Zatím jsem neměl čas pátrat po příčině. Když je zacatek typu char, vše funguje dobře.

Re:602SQL Server a formát datumu
« Odpověď #6 kdy: 31. 03. 2014, 10:06:33 »
Pokud vím, 602SQL Server neumí změnit formát pro implicitní konverzi data nebo času. Podle mne je to ale dost velký nedostatek té aplikace Docházka 3000 – pokud spoléhá na implicitní konverzi mezi datem a textem, a ještě navíc očekává jeden konkrétní formát zápisu data…

Petr Poláček

Re:602SQL Server a formát datumu
« Odpověď #7 kdy: 31. 03. 2014, 11:15:29 »
Chyba to bude asi spíš moje, že se snažím donutit program fungovat s SQL serverem, pro který nebyl vůbec vytvořen. Oficiálně podporuje MySQL a PostgreSQL. Takže spoléhá na něco, co všude jinde normálně funguje a je pravda, že asi nehledá problémy tam, kde normálně nejsou. Je to jen můj experiment.
Mimochodem ten 602SQL si jinak nevede vůbec špatně. Rychlostně se vklínil mezi MySQL a Oracle. Nejrychlejší to zatím bylo s PostgreSQL. A MS SQL vyšel rychlostně stejně jako MySQL. Ale uznávám, že to je hodně specifický test, takže neporovnává přímo schopnosti jednotlivých sql serverů. Spíš z něj vyjde něco jako moje vlastní schopnost / neschopnost donutit jeden program fungovat s různými sql servery, pro které původně vůbec nebyl vytvořen.

Re:602SQL Server a formát datumu
« Odpověď #8 kdy: 31. 03. 2014, 12:12:15 »
Takže spoléhá na něco, co všude jinde normálně funguje a je pravda, že asi nehledá problémy tam, kde normálně nejsou.
Spoléhá na něco, co všude jinde funguje, ale je to určené nanejvýš pro prototypování a normálně by se to vůbec nemělo používat. Svědčí to především o nevhodném přístupu aplikace k databázi – kdyby se tam používalo normální bindování proměnných do SQL dotazů, žádný problém tu neřešíte. Zrovna v případě toho data je možné brát to jako prkotinu a omlouvat to, že s podporovanými databázemi to funguje – jenže se dá předpokládat, že se tenhle přístup používá i jinde v aplikaci, a to už má dopady na její bezpečnost.

Chápu, že si to chcete vyzkoušet a nechci vás od toho nijak odrazovat. Jenom jsem chtěl upozornit, že jste tím odhalil temná zákoutí té aplikace.

Re:602SQL Server a formát datumu
« Odpověď #9 kdy: 31. 03. 2014, 17:00:14 »
Chyba to bude asi spíš moje, že se snažím donutit program fungovat s SQL serverem, pro který nebyl vůbec vytvořen. Oficiálně podporuje MySQL a PostgreSQL. Takže spoléhá na něco, co všude jinde normálně funguje a je pravda, že asi nehledá problémy tam, kde normálně nejsou. Je to jen můj experiment.
Mimochodem ten 602SQL si jinak nevede vůbec špatně. Rychlostně se vklínil mezi MySQL a Oracle. Nejrychlejší to zatím bylo s PostgreSQL. A MS SQL vyšel rychlostně stejně jako MySQL. Ale uznávám, že to je hodně specifický test, takže neporovnává přímo schopnosti jednotlivých sql serverů. Spíš z něj vyjde něco jako moje vlastní schopnost / neschopnost donutit jeden program fungovat s různými sql servery, pro které původně vůbec nebyl vytvořen.

Pozor, když jsem před roky testovat 602SQL, tak relativně rychle běžel s vypnutým fsyncem - tudíž při jakékoliv havárii můžete přijít o data - což se také stávalo - kvůli rychlosti si uživatelé větších aplikací nemohli dovolit zapnout fsync, a když to spadlo (což se stávalo při větší zátěži), tak měli docela problém. Jinak podle jedné konkrétní aplikace se nedá posuzovat databáze. Programátoři většinou mají zkoušenosti a oblibu jedné databáze a ostatní db podporují v rámci možností. Stačí jeden dva neoptimalizované dotazy a výsledek je úplně jiný.

Petr Poláček

Re:602SQL Server a formát datumu
« Odpověď #10 kdy: 31. 03. 2014, 19:30:21 »
Pozor, když jsem před roky testovat 602SQL, tak relativně rychle běžel s vypnutým fsyncem - tudíž při jakékoliv havárii můžete přijít o data - což se také stávalo - kvůli rychlosti si uživatelé větších aplikací nemohli dovolit zapnout fsync, a když to spadlo (což se stávalo při větší zátěži), tak měli docela problém.

Ano, to je pravda. Pokud se zapne zápis změn při commitu, zdvojnásobí se čas odezvy. Například na testované sumární sestavě (12 318 dotazů do databáze) trval výpočet při vypnutém fsyncu 12,8 vteřiny a při zapnutém 25,4.

Jinak podle jedné konkrétní aplikace se nedá posuzovat databáze. Programátoři většinou mají zkoušenosti a oblibu jedné databáze a ostatní db podporují v rámci možností. Stačí jeden dva neoptimalizované dotazy a výsledek je úplně jiný.

Ano, to jsem psal už v předchozím příspěvku. Program je dělaný pro PostgreSQL a tam ta stejná sestava trvá 7,7 vteřiny. Navíc to při mém "testování" běží vlastně jen pro jednoho uživatele a to jak databáze tak OS. V reálném provozu jsou podmínky jiné a tam se může vše chovat jinak, když s tím pracuje najednou víc lidí a ještě se třeba zárověň tahají data z terminálů atd.

Teď zrovna testuju docházku s informixem. K tomu mám trochu nostalgický vztah.  Na něm jsem před 16 lety s SQL začínal. Server byl IBM J30 a potom F50.

Petr Poláček

Re:602SQL Server a formát datumu
« Odpověď #11 kdy: 03. 04. 2014, 09:03:47 »
Trochu se mě podařilo hnout s tím převodem zápisu datumových položek. V php.ini je možné nastavit proměnnou wb_datestring na jedničku a začnou fungovat inserty. Ale při selectu se vrací klasický unixový počet vteřin od 1.1.1970. To se dá pořešit přes PHP funkci date("Y-m-d H:i:s",pocetvterin). Ale pořád to nekonvertuje texty u selectu v klauzuli where.
Takže třeba "insert into a (kdy) values ('2014-01-01')" projde v pohodě a do databáze se správně převede.
Ale "select * from a where kdy='2014-01-01'" neprojde a nadává, že typy nejsou kompatibilní.
Když se datum v podmínce přepíše na 1.1.2014, tak už to projde. Ale to pro mě není řešení.

Ještě jsem narazil na další problém při testování paralelní zátěže více připojených klientů pomocí Apache Jmeteru. Testoval jsem docházku na výkon s různými SQL servery při 2,5,10,20 a 50 současně pracujících uživatelích. U serverů MySQL, PostgreSQL, Firebird, MS SQL, Informix, DB2, Oracle a dokonce SQLite (což není server) nebyl žádný problém a vše perfektně prošlo. Ale 602SQL nezvládl víc jak 10 současně pracujících spojení. Nepomohlo ani nastavení proměnné wb_max_links v php.ini. Přitom v monitoru serveru je u počtu licencí uvedeno Neomezeno. Monitor 602SQL serveru 8.1 žádné chyby nevypisoval, ale víc spojení prostě neprošlo - php skript bežel do vypršení max execution time a pak vrátil Internal server error.

Re:602SQL Server a formát datumu
« Odpověď #12 kdy: 03. 04. 2014, 12:35:35 »
Ještě jsem narazil na další problém při testování paralelní zátěže více připojených klientů pomocí Apache Jmeteru. Testoval jsem docházku na výkon s různými SQL servery při 2,5,10,20 a 50 současně pracujících uživatelích. U serverů MySQL, PostgreSQL, Firebird, MS SQL, Informix, DB2, Oracle a dokonce SQLite (což není server) nebyl žádný problém a vše perfektně prošlo. Ale 602SQL nezvládl víc jak 10 současně pracujících spojení. Nepomohlo ani nastavení proměnné wb_max_links v php.ini. Přitom v monitoru serveru je u počtu licencí uvedeno Neomezeno. Monitor 602SQL serveru 8.1 žádné chyby nevypisoval, ale víc spojení prostě neprošlo - php skript bežel do vypršení max execution time a pak vrátil Internal server error.

602 SQL server je rozporuplný produkt - 602 spálila hodně času i peněz tím, že se měnila koncepce typem od zdi ke zdi (čímž naštvala hodně uživatelů) a ze serveru mám pocit, že jakoby někde v půli vývoje došly peníze a vývoj byl zastaven ještě před dokončením produktu, hlavně před finální optimalizací. Jinak našlápnuto to mělo docela dobře - docela dobrá dokumentace, poměrně úplná implementace SQL, hezké administrační prostředí. Nicméně při performance testech se to chovalo jako produkt, který bych pro produkční nasazení nemohl doporučit - a zkušenosti firem, které nad 602 postavily svoje produkty to potvrzují - což je škoda - možná chybělo málo - a asi i když by to nebyl světový produkt, tak by to bylo použitelné.

To pozadí vývoje 602 SQL serveru a celá historie kolem něj by mne hodně zajímala. Je tu někdo, kdo o tomto projektu něco ví? Případně jestli se mi může ozvat na mail pavel.stehule@gmail.com

Petr Poláček

Re:602SQL Server a formát datumu
« Odpověď #13 kdy: 03. 04. 2014, 18:06:16 »
Jen pro zajímavost sem dám graf, který zatím vyšel z mých měření. Není to ale čisté porovnání výkonu samotných SQL serverů.  Spíš porovnání toho, jak moc se mě podařilo či někdy spíš nepodařilo docházku na konkrétní SQL server napojit.


Při jednouživatelských testech měl nejrychlejší odezvu PostgreSQL, pak MySQL a pak MS SQL. Ale u paralelní zátěže je MS SQL předběhl. Ani se tomu moc nedivím, na rozdíl od prvních dvou je na windows doma (testováno na Win Serveru 2008R2). U Informixu a DB2 bude problém asi v ODBC ovladači. Jinde byly použity nativní funkce php pro konkrétní DB. Jen u toho Firebirdu zatím moc nevím, co ho brzdí.

Graf v žádném případě neříká nic o kvalitách jednotlivých SQL serverů. To jen aby mě někdo nenařknul z tvrzení, že třeba 602SQL je lepší než Oracle. Není. Taky byly použity téměř defaultní hodnoty nastavení po instalaci každého Db serveru, což na výkonu určitě nepřidá. Zejména z pohledu synchronního / asynchronního zápisu na disk při commitu atd.

Tomas Z.

Re:602SQL Server a formát datumu
« Odpověď #14 kdy: 04. 04. 2014, 08:34:12 »
To pozadí vývoje 602 SQL serveru a celá historie kolem něj by mne hodně zajímala. Je tu někdo, kdo o tomto projektu něco ví? Případně jestli se mi může ozvat na mail pavel.stehule@gmail.com
Nejvíc bude vědět vedení 602ky a Januš Drózd, pokud ho seženete (kdysi se i tady na rootu k tomu vyjadřovali, http://www.root.cz/clanky/software602-podcenili-jsme-vyznam-open-source/)

Já měl na starosti okolo přelomu tisíciletí udržování a doplňování Linuxového portu (tehdy to ještě byla Winbase602), tvorbu php modulu a pár dalších věcí, ale od roku 2002 dál už nevím nic. Pokud vás něco zajímá z té doby (a já si to budu pamatovat - je to už dávno, a nebude to citlivá informace - což po těch letech asi už není skoro nic), můžu se ozvat.