F18

osdadoh jutros do pola četiri :(

ali sam ipak došao do najbitnijeg. F18 radi sinhronizaciju:

fin_suban SQL <=> fin_suban.dbf

testirao na knowhow ERP test1 i sinronizacija traje 1.4 sec

par feature-ova bitnih za development

u bin direktoriju se generiše log fajl

hernad@macan:~/github/F18_knowhow$ cat F18.log

recimo sa 192.169 nemam konekcije:

hernad@macan:~/github/F18_knowhow$ cat F18.log

192.168.45.160 / test1 / admin / admin /       5432 / fmk
FATAL:  no pg_hba.conf entry for host "192.169.45.207", user "admin", database "test1", SSL on
FATAL:  no pg_hba.conf entry for host "192.169.45.207", user "admin", database "test1", SSL off

F18.prg¶

glavne varijable na nivo aplikacije sam stavio kao static u ovom F18.prg

static varijable

na njegovom kraju postoje getter funkcije koje te varijable "daju" drugim funkcijama programa:

my_home()
pg_server()
...

gDebug, log_write(cMsg)¶

if gDebug > 5
   log_write("to i to ...")
endif

stavio gDebug := 10 u F18.prg kao globalnu varijablu.

semafori¶

common logika semafora:https://github.com/knowhow/F18_knowhow/blob/master/common/semaphores.prg

sinoć sam puno vremena izgubio na tome što sam u prototpiu uradio implementaciju sa sekvencama a onda sam nakon integracije u F18 počeo dobijati poruke

currvar(...) nikada u ovoj sesiji nije setovan

onda sam se vratio na prvobitnu ideju. sve informacije stavljam u fmk.semaphores_ime_tabele.

konkretno je to urađeno za fmk.semaphores_fin_suban

evo te tabele:

select user_code, algorithm, version, last_trans_version, last_trans_time, last_trans_user_code from fmk.semaphores_fin_suban

"admin";"full           ";26;26;"2011-10-31 00:09:39.21057";"" 
"hernad";"full           ";26;26;"2011-10-31 01:50:05.623303";"" 

evo funkcije koja iz sql-a puni dbf fin_suban_from_sql_server

trenutno je u kodu aktivan samo glupi full algoritam, ali je predivđen date.

my_use¶

u my_use se najviše stvari oko logike semafora dešava

gaDBFs matrica¶

my_use crpi informacije iz gaDBFs. pogledajmo za fin_suban kako izgleda red gaDBFs

četvrti parametar je kodni blok kome prosjeđujemo parametre sinhronizacije keša

ako ovog četvrtog parametra nema my_use tu tabelu ne sinhronizira

fol je u sql transakcijama¶

funkcija koja radi ažuriranje sql tabele

vidimo da imamo start/end/rollback konstrukciju

ažuriranje suban, integritet podataka nam obezbjeđuje sql server¶

evo kako se to koristi

kako ovo funkcioniše ?

unesimo suban stavke u kojima se ponavlja redni broj.

F18 prvo šalje tabele na SQL server, i ako to ne uspije prekida se ažuriranje naloga. Znači imamo server side integritet podataka out-of-box

vrlo je bitno da se prije implementacije semaforma ažuriranje naloga kvalitetno pročisti.

puno vremena mi je oduzelo čišćenje špageti koda koji smo imali

sada je procedura ažuriranja razbijena na čitljiv kod

1. fin_azur_check - logička kontrola prije ikakvih ažuriranja
2. fin_azur_sql - push tu sql server
3. fin_azur_dbf - ako su svi predhodni koraci ok tabela ide i u dbf.

stanje semafora se ažurira tako da se setuje last_user_version za sve stavke tabele (za sve korisnike) a u sopstveno version polje user stavlja novi broj

još puno toga ima da se uradi. sinoć sam već od pospanosti u agoniji radio posljednjih 4-5 sahata ... ali sam koncept se mislim jasno vidi.

kreiranje tabele¶

da još napomenem kako se resetuje brojač kada je nova tabela

    if !FILE(f18_ime_dbf("suban"))
            DBCREATE2("SUBAN", aDbf)
            reset_semaphore_version("fin_suban")
            my_use("suban")
            close all
    endif

reset funkciom se verzija setuje na -1 tako da znamo da će se kod narednog my_usea desiti sinhronizacija.

Ovo nam omogućava da se nakon brisanaj lokalnog keša tabela obavezno regeneriše sa servera.