F18

pushiraj sve sa semaphores_v1.0 i prebaci se na master branch

git checkout master
git pull

dobićeš stanje na kome radim

zadatak je da pripremimo pos u novom okruženju.

logika semafora je skroz promjenjena posebno sa stanovišta definicije sinhronizacije. sada se sve nalazi na jednom mjestu

pos/pos_semaphores.prg su nepotrebne - ne koriste se

ovo je sada mjesto gdje se definišu svi parametri dbf-a i parametri sinhronizacije

https://github.com/knowhow/F18_knowhow/blob/master/fakt/set_a_dbf_fakt.prg#L17

ja sam uradio najvećim dijelom za fin, fakt, epdv

uradio git merge

master <- semaphores_v1.0

tako da su sve promjene koje su rađene na ovom branchu sada u masteru.

switch sa semaphores_v1.0 na master¶

git checkout master
git pull

trebaš dobiti ver 0.9.90

kreiranje set_a_dbf.prg¶

ovdje se definišu parametri koji se već dijelom nalaze u common/a_dbf_legacy.prg (gADBFs)

ja to radim tako što te stavke kopiram pa ih onda uređujem.

pored toga sql_in npr nalazi se u pos/pos_semaphores.prg

kada se formira __f18_dbfs zapis za jednu tabelu gaDBFs se briše.

praktično trebamo izbrisati gaDBFs odnosno a_dbf_legacy.prg u konačnici.

algoritam 1¶

svaka tabela koja ide na sinhro ima barem 1 algoritam za sinhronizaciju

tabele kao što je fin_suban imaju dva.

evo kako primjenjujemo algoritam 2 kod povrata dokumenta:

https://github.com/knowhow/F18_knowhow/blob/master/fin/fin_povrat_dokumenta_priprema.prg#L147

algoritam 2 jednostavno manipuliše tabelom na nivou dokumenta a ne zapisa

server database tabele¶

postojeći ugrade je skroz nepregledan.

uočio sam da su neke tabele u ePDV skroz različite dbf <-> sql

da bih sve to upratio na kraju sam sredio server_db sql

https://github.com/knowhow/fmk/blob/master/database/misc/epdv.sql

tabele dbf - sql moraju biti identične

to sam ovdje započeo:

https://github.com/knowhow/fmk/blob/master/database/misc/epdv.sql#L214

analogno napraviti pos.sql

ePDV tabele su u priličnom haosu .. bojim se da niz stvari u kuf, kif ne odlaze na server

pričam o ranijem stanju naravno

Uveo sam set_a_dbf_pos.prg

commit

po uzoru na set_a_dbf_fakt.prg

tabela pos_pos također uveo da ima dva nivoa algoritma

2 je za dokument (brisanje)

commit

Greške tipa "already in transaction", "outside an transaction" ne smiju se više dešavati¶

Kod ažuriranja i povrata je bilo u sem v1.0 masovna pojava ovih grešaka.

pogledajmo sekvencu

 sql_table_update(nil, "BEGIN")
           update_rec_server_and_dbf(alias(), _vars, 1, "CONT")
           update_sifk_na_osnovu_ime_kol_from_global_var(ImeKol, "w", Ch==K_CTRL_N, "CONT")
  sql_table_update(nil, "END")

bitno je da imamo početak kraj ... a da se unutar toga pojavljulje "CONT" koje označava da je transakcija u toku

sve funkcije (update, delete)_rec_server_and_dbf imaju sada mogućnost da se zada algoritam i transakcija

treba uočiti da je transakcija vezana za ažuriranje više tabela (ne treba zbutniti što se poziva funkcija sql_table_update).

primjer fin ažuiranje¶

trasakcija počinje ovdje

a završava ovdje

ovdje se koristilo update_server_from_rec("fin_suban", "END")

isto bi bilo da je napisano funkcija sql_table_update(nil, "END")

iz jednostavnog razloga što je efekat komnde "COMMIT" transakcije tako da se ime tabele uopšte ne uzima u ozbir.

hm, dobro, to ću pogledati kako u pos ubaciti, idem dodati tabele prvo u sql/db

dodao tabelu #27341

Prilikom ulaska ovu grešku dobijem

F18_IME_DBF (51) set_a_dbf nije definisan za table= _POS_PRIPR

ima li ta tabela u set_a_dbf_pos definisana sa:

set_a_dbf_temp( ... )

Ispravio grešku

commit

alias tabele treba da bude _pos_pripr umjesto _pripr

Šta je dalje ?

Kaže relacija fmk.log ne postoji! I to par puta... u log-u nema ništa.

Vjerovatno treba da postoji na sql/db neka tabela fmk.log, koje vidim nema na serveru.

Saša Vranić je napisao/la:

Šta je dalje ?

Kaže relacija fmk.log ne postoji! I to par puta... u log-u nema ništa.

Vjerovatno treba da postoji na sql/db neka tabela fmk.log, koje vidim nema na serveru.

fmk.log je koliko se sjećam u 4.2.6 db-u instalirana. ima u changelog-u

log_write sada sve operacije stavlja i na fmk.log tabelu što je za dijagnostiku multiuser problema veoma bitno

dobro

prilikom ulaska u pripremu dobijam

segmentation failed

ovo je onaj problem sa oblastima sigurno oko ovih pripremnih tabela

nije nego u šifraniku osoblja i statusa nema ništa (prazni su)

hm... recimo dodavanje nove tarife

Unrecoverable error 9001: Error recovery failure
Called from SET_TABLE_VALUES_ALGORITAM_VARS(292) in common/f18_db.prg
Called from UPDATE_REC_SERVER_AND_DBF(34) in common/f18_db.prg
Called from EDITSIFITEM(904) in common/codes_browse.prg
Called from EDSIF(600) in common/codes_browse.prg

jah, pa nije uopšte ovaj set šifranika ubačen u set_a_dbf_sif()

ROBA, TARIFA, SAST itd...

Saša Vranić je napisao/la:

jah, pa nije uopšte ovaj set šifranika ubačen u set_a_dbf_sif()

ROBA, TARIFA, SAST itd...

za to je predviđen set_a_dbf_sifarnici.prg

Šifranike prebacio tamo gdje im je mjesto

commit

u a_dbfs_legacy.prg ih izbrisao

sada su tarife ok, dodaju se na server itd...

Međutim u POS-u postoji problem sa OSOB / STRAD tabelama

nešto se čudno događa

dodam u tabele vrijednosti, nakon novog ulaska te tabele opet budu prazne itd... ako više puta uđem u njih dobijam segmentation failed grešku

ihhh, stare funkcije scatter() gather() postoje, to je to

Borba sa STRAD i OSOB, commit

Automatsko kreiranje stavki u OSOB i STRAD pri startu korigovano

commit

Kod starta se dakle koristi ova funkcija

pogledaj

koja automatski napuni prazne tabele STRAD i OSOB sa defaultnim podacima...

Interesanta je ova stvar, u sql/db se podaci napune, fakat su tamo a u DBF-u ništa ???

Saša Vranić je napisao/la:

Kod starta se dakle koristi ova funkcija

gdje kod starta ?

Ovo treba pomjeriti kod ulaska u POS modul a ne tamo kod inicijalizacije tabela u f18_init

hm ... pogledao sam u kod, ovo se i dešava kod ulaska u pos modul

poziva se iz ove funkcije f_init_db()

ovu funkciju definitivno treba zamijeniti sa pos_init_dbfs() ... ime treba asocirati na pos

ma da, to ću promjeniti, međutim čitava stvar mi je čudna ?

zašto ima u psql a nema u dbf ?

f_init_db -> pos_init_dbfs

da li ovo ima veze

_rec["id"] := "0" 
 _rec["prioritet"] := "0" 

da li se drugo dobije

ako staviš

_rec["id"] = PADR("0", dužina_id_a) 

itd ... ?

možda semafori ovo traže ... iako to treba fiskirati ako ovaj kod ne radi ...

odvojio ovo u poseban tiket #27366

home baze: /home/vagrant/.f18/f18_test/
current dbf version:       406
    F18 dbf version:       406
err qry: SELECT COUNT(*) FROM fmk.semaphores_pos_dokspf WHERE user_code='test1'err msg:ERROR:  relation "fmk.semaphores_pos_dokspf" does not exist
LINE 1: SELECT COUNT(*) FROM fmk.semaphores_pos_dokspf WHERE user_co...
                             ^

problem sa query-jem: SELECT COUNT(*) FROM fmk.semaphores_pos_dokspf WHERE user_code='test1'

iako sam ažurirao serverdb sa 4.4.1

tabele: semaphores_pos_dokspf nema

ne znam, kod mene postoje te tabele, evo sam odradio upgrade i na drugu bazu i tu su kreirane

nastavljam sutra

problem je bio kod sa mojom testnom bazom

realizacija kase

osposobio sam ovaj izvještaj, problem kreiranje POM tabele itd... sada je napravljeno kako treba

treba pročistiti i ostale izvještaje, i tu postoji POM tabela

ažuriranja sam očistio

commit

tu je i POS blizu iskoristivom stanju

commit

još borbe sa izvještajima...

reporti svi ispravljeni

commit

ostala samo još opcija generisanja fajla razmjene za KALK (prenos realizacije u KALK) i sve je spremno

izbacio dosta stvari

commit

commit

još čišćenja

commit

commit

Riješio i sve tipove prenosa pos - kalk

• f18 pos->kalk, kalk->pos
• f18 pos <- fmk kalk
• f18 kalk <- fmk pos

#27085

ažuriranje zaduženja, imao sam duplu transakciju

ažuriranje zaduženja a unutar toga azurroba() funkcija

commit

testirao sam multi user rad i semafore, rade ko čvoka

očistio sam pos od svakakvih budaleština, tipa ono sklanjanje računa itd...