F18

postojeći standardni $HOME je user 1

napravimo na drugoj konzoli:

mkdir /home/hernad/f18_test_1

tu napravimo .f18 direktorij i podrirektorije

export HOME= /home/hernad/f18_test_1

cp _tamo_gdje_se_nalazi_F18_exe /homer/hernad/f18_test_1/F18_test_1

pokrenemo F18_test_1

logiramo se kao drugi user i testiramo konkurentni rad. svaki user će imati svoje dbf-ove za rad

u trećoj konzoli možemo napraviti isto za trećeg usera ...

podesio višekorisnički rad i evo testiram modul FIN...

uočio sljedeće

• konzola 1: napravim nalog - ažuriram - kontrola zbira - ok
• konzola 2: idem na kontrolu zbira - osvježi podatke (vidim po poruci na dnu) i izbaci me sa nepostojećim alijasom

skontao sam gdje je belaj...

naime, funkcija fin_suban_from_server() nakon što odradi osvježavanje prije izlaska iz funkcije ima close all komandu

https://github.com/knowhow/F18_knowhow/blob/master/fin/fin_semaphores.prg#L178

pa tako kada ulazimo u kontrolu zbira datoteka, desi se da se tabela osvježi ali nam i zatvori sve :)

Ukinuo close all i nakon toga radi kako treba i dobro se osvježavaju podaci...

https://github.com/knowhow/F18_knowhow/commit/c54fcbaea93b971a8bab22cef336b9420d88b609

ostalo koliko vidim fino radi...

pregled naloga, novi nalog - brojač radi kako treba itd...

isto primjenio na fakt, kalk

https://github.com/knowhow/F18_knowhow/commit/c6cf7d936057412d09ffb311f8814f14d63f83d8

Nakon što sam napravio ažuriranje fakt dokumenta testiram ga u više korisničkom radu i mogu reći da ne radi ! :)

Vidim da se desi semafor opcija recimo kada ulazim u pregled dokumenata međutim u listi nemam tog novog dokumenta.

Ako bi slučajno pobrisao tabelu fakt_doks i ušao ponovo on mi fino povuče sa servera podatke.

?!????

konačno našao u čemu je problem, problem je u dijelu gdje se provjeravaju _ids

ažurira se u semafor broj dokumenta ovako, npr

('101000252')

a kod pretrage je broj dokumenta gleda se kompletna dužina i onda on traži

('101000252   ')

i stoga nije skontao da ima nešto za osvježiti

sada nakon korekcije radi

https://github.com/knowhow/F18_knowhow/commit/a87abd2d6596448494e99907bd180bd49bbd0398

i fakt/ugovori se fino koliko vidim osvježavaju

eh, pošto je jasko napravio test okruženje sa bring.out podacima možemo prionuti na testiranje u realnim okolnostima, a i preko vpn-a

F18 build sam pripremio kod sebe a pripremam i kod žekija

Error BASE/1132 Bound error: array access

Called from SQL_KALK_DOKS_UPDATE(577)  
Called from KALK_AZUR_SQL(831)  
Called from AZUR_KALK(79)  
Called from KALK_PRIPR_KEY_HANDLER(238)  
Called from (b)KALK_UNOS_STAVKI_DOKUMENTA(153)  
Called from OBJDBEDIT(195)  
Called from KALK_UNOS_STAVKI_DOKUMENTA(153)  
Called from KALK_UNOS_DOKUMENTA(67)  
Called from (b)TKALKMOD_MMENUSTANDARD(84)  
Called from MENU_SC(1787)  
Called from TKALKMOD:MMENUSTANDARD(143)  
Called from TKALKMOD:MMENU(67)  
Called from TKALKMOD:RUN(149)  
Called from MAINKALK(30)  
Called from MAIN(73)

ispravio grešku

testirali smo rad, ja napravim dokument, jasko napravi dokument i to radi fino

u isto vrijeme bi trebalo da pravimo dokument, nekoga će odbaciti vjerovatno ! sad ćemo probati

u isto vrijeme, mene je jednostavno odbio a jasku je dozvolio, a meni rekao da postoji duplicate key

ok

Šifrarnici¶

poigrali se i sa šifrarnicima, i to radi kako treba

postoji samo jedna sporna stvar

kada idem na opciju F2 recimo, treba i tada da se desi sinhronizacija - a ne desi se

otvorio tiket #25459

FAKT nakon štampe TD 10

Error DBCMD/2001 Workarea not in use: ORDSETFOCUS

Called from ORDSETFOCUS(0)  
Called from O_FAKT_EDIT(59)  
Called from PRINTDOK(740)  
Called from FAKT_PRIPR_KEYHANDLER(329)  
Called from (b)FAKT_UNOS_DOKUMENTA(99)  
Called from OBJDBEDIT(195)  
Called from FAKT_UNOS_DOKUMENTA(99)  
Called from (b)TFAKTMOD_MMENUSTANDARD(84)  
Called from MENU_SC(1787)  
Called from TFAKTMOD:MMENUSTANDARD(144)  
Called from TFAKTMOD:MMENU(69)  
Called from TFAKTMOD:RUN(149)  
Called from MAINFAKT(30)  

Error DBCMD/2001 Workarea not in use: ORDSETFOCUS

Called from ORDSETFOCUS(0)  
Called from O_FAKT_EDIT(40)  
Called from PRINTDOK(737)  
Called from FAKT_PRIPR_KEYHANDLER(325)  
Called from (b)FAKT_UNOS_DOKUMENTA(99)  
Called from OBJDBEDIT(195)  
Called from FAKT_UNOS_DOKUMENTA(99)  
Called from (b)TFAKTMOD_MMENUSTANDARD(84)  
Called from MENU_SC(1787)  
Called from TFAKTMOD:MMENUSTANDARD(144)  
Called from TFAKTMOD:MMENU(69)  
Called from TFAKTMOD:RUN(149)  
Called from MAINFAKT(30) 

Error DBCMD/2001 Workarea not in use: ORDSETFOCUS

Called from ORDSETFOCUS(0)  
Called from O_FAKT_EDIT(30)  
Called from PRINTDOK(737)  
Called from FAKT_PRIPR_KEYHANDLER(325)  
Called from (b)FAKT_UNOS_DOKUMENTA(99)  
Called from OBJDBEDIT(195)  
Called from FAKT_UNOS_DOKUMENTA(99)  
Called from (b)TFAKTMOD_MMENUSTANDARD(84)  
Called from MENU_SC(1787)  
Called from TFAKTMOD:MMENUSTANDARD(144)  
Called from TFAKTMOD:MMENU(69)  
Called from TFAKTMOD:RUN(149)  
Called from MAINFAKT(30) 

ovo je nevjerovatno, na mac-u radi ovo sve, na lx-u neće... kada smo u debug-u radi normalno, normalno otvori ove tabele

naime, puca na O_OPS

i u debug režimu normalno otvori tabelu, a kada nije u debug-u pukne

interesantna je još jedna stvar, na lx-u nema kupca na fakturi kada se odštampa, na mac-u ima ?!???

Saša Vranić je napisao/la:

interesantna je još jedna stvar, na lx-u nema kupca na fakturi kada se odštampa, na mac-u ima ?!???

toi je do printerskih kodova

#%10CPI##%BON__#Kupac:
#%KON17#      #%10CPI#-------------------------------#%IOFF_#
#%KON17#      #%10CPI##%BON__#  AGENCIJA MDM                       #%BOFF_#                  Zenica, 30.11.11
#%KON17#      #%10CPI##%BON__#  4.MUSLIMANSKE 14/14                #%BOFF_#          Datum isporuke: 30.11.11
#%KON17#      #%10CPI##%BON__#  KONJIC                             #%BOFF_#
#%KON17#      #%10CPI#  ID broj: 9999999999999             
#%KON17#      #%10CPI#  #%12CPI#fax: 036734191                     #%10CPI#

kada setujemo štampač 0 i pobrišemo kodove tada je OK, ali ovo podešenje ne preživi restart F18, kada ponoov uđemo, kodova nema u podešenju ali F18 generiše outf.txt oopet sa kodovima.

prođemo samo kroz podešenja i onda je OK

kod promjena u šifrarnicima osvježavaju se karakterna polja dok numerička NE !!!

Saša Vranić je napisao/la:

kod promjena u šifrarnicima osvježavaju se karakterna polja dok numerička NE !!!

da, hernad je to kod šifrarnika previdio ...

korigovao funkciju f18_gather()

https://github.com/knowhow/F18_knowhow/commit/f88e99721113d0c847fb0ea8d081066cf0cf444b

sad je sinhro ok

kod prvog pokretanja ili izmjene baze

Error BASE/2020 Argument error: PQRESULTSTATUS

Called from PQRESULTSTATUS(0)  
Called from TPQQUERY:REFRESH(579)  
Called from TPQQUERY:NEW(537)  
Called from TPQSERVER:QUERY(200)  
Called from SET_SQL_SEARCH_PATH(82)  
Called from MY_SERVER_LOGIN(126)  
Called from INIT_F18_APP(66)  
Called from MAIN(41)

Error BASE/1003 Variable does not exist: ZANIVEL

Called from (b)FIELDBLOCK(0)  
Called from SIFRARNIK_FROM_SQL_SERVER(676)  
Called from ROBA_FROM_SQL_SERVER(90)  
Called from (b)SET_A_DBFS(55)  
Called from MY_USE(87)  
Called from CREROBA(64)  
Called from TDBFAKT:KREIRAJ(236)  
Called from TDBFAKT:NEW(35)  
Called from TFAKTMOD:INITDB(49)  
Called from SC_START(91)  
Called from TFAKTMOD:RUN(141)  
Called from MAINFAKT(30) 

fin prilikom štampe

Error DBCMD/2001  Workarea not in use: ORDSETFOCUS
Called from ORDSETFOCUS(0)  
Called from SINTSTAV(219)  
Called from STNAL(22)  
Called from EDIT_FIN_PRIPR(747)  
Called from (b)KNJNAL(137)  
Called from OBJDBEDIT(195)  
Called from KNJNAL(137)  
Called from FIN_UNOS_NALOGA(88)  
Called from (b)TFINMOD_MMENUSTANDARD(91)  
Called from MENU_SC(1787)  
Called from TFINMOD:MMENUSTANDARD(168)  
Called from TFINMOD:MMENU(76)  
Called from TFINMOD:RUN(149)  
Called from MAINFIN(35) 

Saša Vranić je napisao/la:

interesantna je još jedna stvar, na lx-u nema kupca na fakturi kada se odštampa, na mac-u ima ?!???

na par mjesta sam uočio onaj "^M" znak (DOS znak za novi red). takve stvari mogu praviti probleme koji se manifestuju time da na jednom sistemu radi a na drugom ne radi.

znači linux takav znak za novi red ignoriše, a mac i windows ne ignorišu.

nije do linux-a nego do koda :)

dobro, na lx-u je znači ostao legendarni problem s otvaranjem tabela nakon štampe ?!???

fin : http://redmine.bring.out.ba/issues/25378#note-34
fakt: http://redmine.bring.out.ba/issues/25378#note-25

kod mene na mac-u to radi kako treba.

čak sam se na fakt-u igrao sa timeout-om pa stavljao sleep(5)

i kada pustimo prvi put štampu i zatvorimo - sve ok

kada pustimo drugi put štamopu - nekada bude opet ok a nekada izbaci da ne može otvoriti tabelu

baš onako zanimljiva stvar

pa dobro daj otvori ticket za to poseban i stavi link na github source gdje se problem dešava

jesi li probao ovo dodati na spornom mjestu:

SELECT F_PROBLEMATICNA
use
O_PROBLEMATICNA

na ovaj način ćeš uvijek znati da je prije novog otvaranja tabela zatvorena.

na sličan način sam ja riješio problem kada si bio ovdje u kancelariji i čudio se nad ponašanjem linux-a u odnosu na mac.

otvorio sam tiket #25463

testirali i finansije - ok sinhronizacija

moram napomenuti još da smo testirali kompletan dan rad na remote serveru preko vpn-a - užasno sporo radi

Saša Vranić je napisao/la:

moram napomenuti još da smo testirali kompletan dan rad na remote serveru preko vpn-a - užasno sporo radi

navedi par operacija koje potvrđuju ovaj navod - scenario korištenja, vrijeme pojedinih operacija.

otvorio poseban ticket za to #25464.

Tu mi je nešto čudno ažuriranje dokumenta sa IDS algoritmom ne bi smjelo biti sporo. tu nema nikakvog značajnog client-server prometa.

Većina operacija treba biti sa lokalnim dbf-ovima tako da to ne bi uopšte trebalo ovisiti o lokaciji servera.

najprije da smo nešto pogrešno napravili.

kako god. napravi test i stavi ga na benchmark ticket pa ćemo analizirati.

Sve u svemu ja sam se recimo jučer više bazirao na funkcionalnost, tako da sve ove bazne funkcije stavim u funkciju, pošto je i tu bilo svega.

malo gledao ažuriranje u fakt-u, recimo 5-put su se otvarale sve tabele (O_FAKT... itd...)

korigovao to

https://github.com/knowhow/F18_knowhow/commit/56e64de743fe11afeffc1b9cd7e8cc699d46fc2f

sigurno da će ažuriranje sada ići brže, jer je svaki put radio O_FAKT recimo i svaki put gledao ima li šta za sinhronizaciju i pozivao semafor funkcije

identična stvar je i kod štampe - pretpostavljam, tamo se vjerovanto još više puta poziva o_fakt_edit() funkcija

nakon zadnjeg pull-a imam grešku

Error DBFCDX/1001 Open error: /home/bjasko/.f18/bringout_test/dracun.dbf (DOS Error 2)

Called from DBUSEAREA(0)  
Called from MY_USE(114)  
Called from O_FAKT_EDIT(58)  
Called from FAKT_UNOS_DOKUMENTA(32)  
Called from (b)TFAKTMOD_MMENUSTANDARD(84)  
Called from MENU_SC(1787)  
Called from TFAKTMOD:MMENUSTANDARD(144)  
Called from TFAKTMOD:MMENU(69)  
Called from TFAKTMOD:RUN(149)  
Called from MAINFAKT(30) 

dracun ne postoji lokalno to sam provjerio

a ha

evo odradi pull

https://github.com/knowhow/F18_knowhow/commit/df8f199951744c6a41fcfb01a9b35cbd996bfe26

sad je ok osim ovog legendarnog ORDSETFOCUS :)

pregled > štampa liste dokumenat u faktu, užas sporo, sve jedan po jedan dokument izbacuje, kao drito sa baze da to radi a ne loko

da, i kod mene isto...

jasko, puluj

epdv probaj da li ti radi

i dodaj nešto u kuf i kif pa ažuriraj

napravio jedan kuf/kif dokument ažurirao, pregledao ...OK, ulaz šifrarnici su OK

generacija !OK

Error BASE/1081 Argument error: +

Called from GEN_SG_ITEM(163)  
Called from FAKT_KIF(124)  
Called from GEN_KIF(60)  
Called from (b)EPDV_GENERISANJE(25)  
Called from MENU_SC(1787)  
Called from EPDV_GENERISANJE(27)  
Called from (b)TEPDVMOD_MMENUSTANDARD(90)  
Called from MENU_SC(1787)  
Called from TEPDVMOD:MMENUSTANDARD(127)  
Called from TEPDVMOD:MMENU(58)  
Called from TEPDVMOD:RUN(149)  
Called from MAINEPDV(30) 

ok, to su sada direktoriji, probaj uputiti na pravi direktorij do sifrarnika i kumulativa, tj. postavi home path u one šeme generisanja, trebalo bi da radi

fakt, šumaher od pregleda dokumenata

puluj :)

Saša Vranić je napisao/la:

ok, to su sada direktoriji, probaj uputiti na pravi direktorij do sifrarnika i kumulativa, tj. postavi home path u one šeme generisanja, trebalo bi da radi

bogum ista greška

path /home/bjasko/.f18/bringout_test

ORDSETFOCUS greška se javlja i kod štampe iz pregleda

de ovaj ptxt poziv sredi pa da na windozama probamo

ptxt se poziva bez putanje

https://github.com/knowhow/F18_knowhow/commit/6a78a1ca3a5dcf4e4cc0ca64528328f83b527d23

puluj

epdv generisanje, problem #25475

Saša Vranić je napisao/la:

ptxt se poziva bez putanje

https://github.com/knowhow/F18_knowhow/commit/6a78a1ca3a5dcf4e4cc0ca64528328f83b527d23

puluj

e tako to sada na windozetu radi OK, samo izbaci dodatni dos prozor

imam filing da ovaj f18_edit kod štampe na ekran ove ORDSETFOCUS greške pravi, ptxt nema taj problem

"bubanje" na jedan ticket¶

malo sam zbunjen kako je oko ovog problema čitava saga nastala. pričam o ORDSETFOCUS grešci.

napravite na tačci gdje se prijavljuje problem (tačnije ispred) isti recept

if !used()
open tabelu
endif

i to je to. zar je to problem ?

ali ako jeste. dajte to izdvojite kao bug ordsetfocus i to pregledno dokumentujte. ovaj ticket je postao totalno nepregledan.

generalno stvarate iluziju da ćete "bubanjem" na jedan ticket uštediti na vremenu.

dajte da se problemi koji su zasebne cijeline vide kao takvi.

ovako samo iz chat-a mogu uloviti stanje operacija što nije dobro. razlog je upravo pomenuto "bubanje" na jedan ticket

by the way ORSETFOCUS, to dobro znamo, nema veze sa višekorisničkim radom. to je problem koji ste TOKOM rada na ovom ticketu uočili i sa njima veze nema.

vsasa: a kako mi to bubamo? postoji tiket za problem ordfocusa
hernad: ma dobro eto nazovi kako hoćeš ako ti smeta termin bubamo
hernad: sada vidim ticket koji govoriš
hernad: međutim na ovom dugačkom vrti priča oko njega
hernad: ali da podvučemo čizu
hernad: bez obzira što "gori", kada se locira novi problem ticketirajte ga. tako će se u pregledu ticketa vidjeti glavne operacije i glavni problemi. to je sve što tražim.

Štampa fakture, problem sa sporosti #25478

možda sam to već negdje spominjao, ali nije zgoreg još jedanput

prebacivanje podataka između modula #25479

sigurno će biti problem

import elba podataka #25480

najvjerovatnije bude problem

Saša Vranić je napisao/la:

import elba podataka #25480

najvjerovatnije bude problem

kakve veze ima elba sa testiranjem višekorisničkog rada.

Saša Vranić je napisao/la:

prebacivanje podataka između modula #25479

kakve veze ima sa višekorisničkim radom ?

Saša Vranić je napisao/la:

Štampa fakture, problem sa sporosti #25478

kakve veze ima sa višekorisničkimr radom

Ernad Husremović je napisao/la, note-2

podesi kod sebe

da li si ti uopšte ovo uradio ?

hmm mislim da razumijem ti si pod ovim smatrao sve funkcije portiranja - pushiranja podataka na server.

to nije testiranje višekorisničkog rada zato ste se čudili što vam govorim šta "bubate". A bubali ste samo tako.