F18

uočavam 5-6 bugova i niz problema koje izaziva promjena parametara - prebacivanje na server db.

to se jedno po jedno fiksira ali to tako ne treba. To treba fiksirati u F18 core funkcijama)

u set_metric / fetch_metric treba te stvari fiksirati ... a ne na svakom djelu aplikativnog koda

aplikativni developer ne treba misliti o konverziji parametara.

principi¶

1) na sql serveru podaci MORAJU biti pohranjeni u utf formatu. utf je 2-bajt format za naša slova.

2) memorijske varijable u harbour-u (ono što se čita u @ GET, SAY ...) moraju biti pohranjene u OEM 852 formatu

što se za utf stringove dobija sa hb_utf2str( ...).

Ako se ova konverzija ne izvrši onda dobijamo u maski za unos podataka nešto kao "LoliXY" umjesto "Lolić" pri čemu su XY neki čudni znakovo - to korisnici prijavljuju kao smeće, hijeroglifi

šta uraditi¶

u aplikativnom kodu - kodu koji koristi fetch_metric set_metric treba izbaciti konverzije

u get_metric treba staviti konverziju

gledam fetch metric funkciju:

if _ret == "!!notfound!!" 
   // NOT FOUND metric, raise exception 
   return default_value 
else  
   return str_to_val(_ret, default_value) 
endif 

pod pretpostavkom da su na serveru podaci u utf-formatu (tako mora biti ako nije !)

treba dodati ovo

static function str_to_val(str_val, default_value)
local _val_type := VALTYPE(default_value)

do case
    case _val_type == "C" 
        return hb_Utf2Str(_val)  <<<<<<<<<<<<<< ili hb_Utf8ToStr ... kako već glasi ime fje <<<<<<<<<<<<<

    case _val_type == "N" 
...

tako će string varijabla kojim manipuliše GET/SYS uvijek imati OEM cp852.

hah evo upravo sada vidim da je to zakrpljeno ako ne treba - u aplikativnom dijelu koda :(

sinoć je saša to radio ovako

imamo znači "milion" bezpotrebnih konverzija u aplikativnom dijelu

fetch_metric sada vraća za stringove hb_utf8tostr

commit

commit

uklonio kod čitanja parametara ovu konverziju iz aplikativnog dijela koda