Aktivnost
Od 27.10.2012 do 25.11.2012
23.11.2012
-
16:27 Greške #29667: bringout, problem sa semaforima 3 put
- Znači sada sam testirao rad i sada fino osvježava i dobijem sve što je naknadno došlo u semafore...
Ostalo još da se naprave
* isključiti ALERT-e kod ovih retry operacija
* pronaći uzrok problema što se ne setuje ova verzija -
- i još jedna stvar, kod ovog ponavljanja treba uvesti da se ne pojavljuju alerti
-
- ovo si garant ti nešto čačkao
-
- e sada jedna stvar koju sam primjetio je da kada se radi update_rec... verzija se ne setuje kako treba
znači nakon update-a podataka imam: -
16:02 Greške #29667: bringout, problem sa semaforima 3 put
- by the way nemoj se zaboraviti prijaviti na trello trebaće mi to
-
- ok :)
sada sam napravio test i uspješno dobio 2 promjene....
idem sada izbaciti i iz ažuriranja one sleep itd....
-
- buni se travis https://travis-ci.org/knowhow/F18_knowhow/builds/3327966/#L101
-
- izbaci altd iz repozitorija ako ti je ostalo
-
- Saša Vranić je napisao/la:
> izbacio to i ispravio ovu grešku sa return, praktično return treba da vrati get_ids_.... zato što ona vraća niz
> ...
od nas dvojice jednog pametnog čovjeka bi mog'o napravit' -
- izbacio to i ispravio ovu grešku sa return, praktično return treba da vrati get_ids_.... zato što ona vraća niz
"commit":https://github.com/knowhow/F18_knowhow/commit/7aef257e370bcbb87e05d225fe946c6d51f815c6
-
- ne da je nepotrebno nego je suvišno
-
- ovo je nepotrebno:
https://github.com/knowhow/F18_knowhow/blob/36972feef850d6480f1bd058595838f32b08cd51/common/semaphores_ids_algoritam.prg#L285
jer smo već u get_ids_... nulirali
-
- napravi pull novi pa testiraj sa novim buildom
-
- je li sada progulilo ?
svejedno, dodao sam return nakon rekurzivnog poziva ... mislim da je to bilo problematično. -
-
- ne mogu se zakačiti više za testni pgsql... nešto je puklo oko interneta, redmine jedva radi
-
- nešto interneta nestade....
"commit":https://github.com/knowhow/F18_knowhow/commit/36972feef850d6480f1bd058595838f32b08cd51
ispravio sam grešaka....
sada kada sam pokrenuo isti test, desio se rollback i ponovo je ušao u funkciju... -
- stanje semafora:
-
- moralo bi da je ponovi - da uradi rollback (čime bi rekao - ok ja nisam ništa uradio) i da ponovi select, ali ovaj put sa željkinim dokumentima ...
I to bi bilo praktično rješenje problema.
Mislim da smo napokon blizu rješenja :) -
- ne ne, to je prije ovoga što si ti napravio... idem sada sa ovim novim bildom
-
- Saša Vranić je napisao/la:
> E sada pošto sam ubacio ovo SET TRANSACTION.... rezultiralo mi je greškom kako si i rekao. CURRENT TRANSACTION ABORTED... i izbacio me.
a šta je sa verzijom koja handlira grešku ? da li ponovi transakciju ? -
- E sada pošto sam ubacio ovo SET TRANSACTION.... rezultiralo mi je greškom kako si i rekao. CURRENT TRANSACTION ABORTED... i izbacio me.
-
- stanje semafora fakt_doks prije testa
-
- dodao sam commit koji radi rollback a nakon toga radi retry a ne QUIT !
-
-
- nešto slično se ovdje dešava: http://wiki.postgresql.org/wiki/SSI
trebala bi se desiti greška -
- ali će se onda desiti gledajući ovaj kod "QUIT iz aplikacije ?":https://github.com/knowhow/F18_knowhow/blob/5fe272caf2b39a15c72d5ef38b1921d789707035/common/semaphores_ids_algoritam.prg#L178
-
- šta to znači trebamo imati
-
- > UPDATE IDS = NULL i setujem na verziju tekuću a to je 501 tako da ću ovo što mi je željka ubacila samo prebrisati
verzija će biti 500, to znam.
Ali ne znam kakve ću id-ove imati nakon izlaska iz transakcije.
1) da li će moj N... -
- ovdje stavite "run_sql_query( BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE ) ":https://github.com/knowhow/F18_knowhow/blob/5fe272caf2b39a15c72d5ef38b1921d789707035/common/semaphores_ids_algoritam.prg#L167
-
- još samo to probajte: )
-
- Da ... do je čista reprodukcija problema
Hajde probajte sa varijantom u kojoj se ovo nuliranje obavlja sa
run_sql_query("BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE")
umjesto sa običnim "BEGIN" -om kako je sada -
- a generalno, ako postavim break point između
* SELECT IDS
* UPDATE IDS
i sačekam da željka ubaci dokument mogu vidjeti šta se desilo sa mojim semaforom
desit će pretpostavljam ovo:
IDS = SELECT IDS verzija 500 < imat ću tu j... -
- Saša Vranić je napisao/la:
> ja ću se prebaciti na ove druge stvari, već sam dobro skašen od ovoga
Ma da to je najbolje. Ovo je fakat pravo "pipavo" i zamorno ... Čovjeku se mozak bukvalno "skvrči" od razmišljanja na ovu temu :)
U... -
- http://www.postgresql.org/docs/9.1/static/transaction-iso.html#MVCC-ISOLEVEL-TABLE
defaultni "READ COMMITED" isoltaion level transakcije omogućava da se u toku transakcije *VIDE* stvari drugih transakcija koje su završene
Korisnici... -
- ja ću se prebaciti na ove druge stvari, već sam dobro skašen od ovoga
-
- Saša Vranić je napisao/la:
> Nisam uopšte usmjerio energiju na lock/nelock samo analiziram šta se desilo i radi čega, a to je prikazano u ovim isječcima logova
Objasniću ti šta mislim pod ovim.
Kod dijagnostike treba hipoteze stav... -
- Saša Vranić je napisao/la:
> Jedina stvar koja mi je sinula je sljedeća
> ...
SQL transakcija bi trebala da obezbjedi integritet. To znači da bi drugi korisnik trebao da vidi ili sve ili ništa.
Tvoje pitanje govori da još dosta tog... -
- u 126 komentaru kažeš:
-
- Nisam uopšte usmjerio energiju na lock/nelock samo analiziram šta se desilo i radi čega, a to je prikazano u ovim isječcima logova
-
- Ernad Husremović je napisao/la:
> Saša Vranić je napisao/la:
> ...
pa stavljao sam dijelove loga koji su bitni sa komentarima šta se događalo -
- Jedina stvar koja mi je sinula je sljedeća
* može li biti da sam imamo u IDS-u markiran dokument 10-10-000400 a da u fakt_doks tabeli na serveru taj dokument još nije stigao ?
ovo govorim iz onih razloga što se dešavalo da nestaju ... -
- > common/semaphores_full_algoritam.prg: run_sql_query("BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE")
-
- Vezano za primjer koji si gore naveo note-126:
> // nuliram IDS i setujem verziju na 501
> ...
u toku tvoje SQL transakcije željka završi svoju SQL transakciju.
To mi je nejasno s obzirom da obje transakcije rade update iste ta... -
- Što se tiče ovog problema, radi na njemu do 14:00 max.
Svakako će analiza loga ili testovi sa željkom biti najkorisniji u tom periodu da što više "ogolimo" - izolujemo problem.
Nakon toga se ponovo vrati na pripreme za ramaglas, n... -
- Saša Vranić je napisao/la:
> Dobro, log nam je sada fino pokazao stvar, jesi uočio šta se desilo ?
> ...
ne nisam dovoljno detalljno pročio. zakači log u cjelosti od jutros, u kom vremenskom period se desio konflikt. takođe sortiraj l... -
- > rezime nije u transakciji, rezime je da get_ids_from_semaphore() mora biti pod lock-om, praktično tada niko ne smije upisivati ništa u moj IDS dok ja ne pokupim i setujem na verziju
Dobro. Vidim da svu svoju energiju i analizu usmje... -
- Dobro, log nam je sada fino pokazao stvar, jesi uočio šta se desilo ?
Ja sam iznjeo problematiku, a šta je rješenje... to ne znam.
-
- Saša Vranić je napisao/la:
> to sam i prije 15 dana isto uočio na prvim testovima a evo se pokazalo sada sa novim logiranjem i tačno
Jedino je tačno da nismo postigli cilj, stvar ne funkcioniše. To što ti zadnjih 15 dana ponavljaš ni... -
- saša, dosta puta sam rekao, ali to očigledno nismo apsolvirali
Ovo je polazište. Molim te da ga pažljivo pročitaš http://redmine.bring.out.ba/issues/29667#note-83
Ta priča o lock/free operacija na aplikativnom nivu kod operacija či... -
- to sam i prije 15 dana isto uočio na prvim testovima a evo se pokazalo sada sa novim logiranjem i tačno
-
- taj lock bi bio jako kratak, praktično lock samo dok ne uradi
* SELECT
* UPDATE
ali je problem što je tabela već lock-ovana od strane željke....
-
- da bude reprezentativnije, događaj je ovakav:
-
- ovo je opasno:
-
- evo dijela log-a
-
- evo, napravio sam tako.... opet smo kuckali i opet sam isprovocirao problem
* imao sam da osvježim jedan dokument
* željka pravila novi i bila u procesu ažuriranja između ona dva sleep-a
* ja sam rekao F5 u pregledu i dobio sao fakt... -
- ako je ovaj nasilni (timeout) unlock od strane jaska izazvao gutanje te stavke, test koji si radio *NIJE REPREZENTATIVAN*
-
- > 1) bjasko odradio odradio unlock fakt_doks iako ga je vzeljka lock-ovala
postoji timeout vrijeme kod unlocka - nakon tog vremena user može unlockovati tabelu čak iako je u stanju "locked"
to je uvedeno da se ne bi desili dead lo... -
- pa i nije situacija kao jučer, imamo sada ove dvije kritične tačke
1) bjasko odradio odradio unlock fakt_doks iako ga je vzeljka lock-ovala
2) bjasko napravio sinhronizaciju podataka sa verzijom koju je on napravio
-
- i evo mislim potpuno identična situacija log-a kao i jučer....
-
- nisam siguran "šta će user dobiti u update statementu za last_trans_version ":https://github.com/knowhow/F18_knowhow/blob/5fe272caf2b39a15c72d5ef38b1921d789707035/common/semaphores_ids_algoritam.prg#L168
zato dodaj version, last_tran... -
- > jutros nastavili testove, i evo od 15 dokumenata jedan je opet izgubljen, ali nažalost ne mogu se sjetiti šta sam uradio i u kojem momentu...
> ...
Rekonstruiši događaje na osnovu logova. Ako nešto fali, dopuni log funkcije. -
- fali mi dokument *10-10-00342*
u nekoj fazi sam lupio F5 i tačno sam vidio da je samo fakt_fakt i fakt_doks2 osvježen, odmah sam znao da će dokument faliti, ali ne mogu se sjetiti u kojoj fazi (mislim na to u kojem je dijelu bila želj... -
- jutros nastavili testove, i evo od 15 dokumenata jedan je opet izgubljen, ali nažalost ne mogu se sjetiti šta sam uradio i u kojem momentu...
znači kod željke je sleep prije i nakon puširanja...
opcija da štampam fiskalni račun upo... -
- ee znao sam :) hajd super
-
10:41 Greške #29664 (Zatvoreno): LD, specifikacija nema naših karaktera u nazivu firme itd... (Linux instalacija)
- pa eto kada se bude išlo ili davalo podršku postaviti
-
- u slučaju da nema treba instalirati SL pack
sudo apt-get install language-pack-sl-base -
- u pozivu wine-a fali sl_SI.UTF8 attachirana je ispravljena
-
- bjasko probaj ti kod sebe na ubuntu sesiji vidjeti da nije do wine-a i podešenje codepage-a
22.11.2012
-
- treba napraviti te testova sa dužim pauzama. bez obzira na njih, ne bi se smjelo dešavati "gutanje" dokumenata
Slično kao pauze unutar ažuriranja, pauzu treba dodati
pauzu treba dodati i pauzu između "selecta i update-a ovdje":https... -
- Prije ovoga smo napravili opet jedan test sa grupom faktura nekih 10, sada je sve ok, imamo isto stanje.
Moguće je da smo problem riješili.
Sutra ćemo napraviti opet veliki test sa 30-ak faktura i simultanim radom. Sada moram ići. -
- testirao pauze - transakcija izoluje sve promjene - promjene se ne vide dok se transakcija ne okonča.
Sada će biti interesantno napraviti gornji test.
"izbrisao sam pauze":https://github.com/knowhow/F18_knowhow/commit/4e3fb408936... -
- Saša Vranić je napisao/la:
> aaaaaa momenat momenat, ne vjeruješ ti meni :)
i dalje nisam siguran da smo riješili problem. Ako ti to znači šta ne vjerujem ni tebi ni sebi.
Reprodukcija bug-a nije 100% sigurna, što znači da ni uzrok nij... -
- napravio sam novi commit koji onu one sql transakciju razbija na više upita prema serveru, ali opet transakcija
-
- update fmk.semaphores_fmk_test set version=999 where user_code='hernad' returing version, last_trans_version =>
vratiće stanje polja *nakon* update operacije -
- aaaaaa momenat momenat, ne vjeruješ ti meni :)
-
- http://stackoverflow.com/questions/6763692/postgres-update-after-select
-
- Ernad Husremović je napisao/la:
> ali to što si napisao ne radi u sql-u ...
znam :) nego samo ono što treba da se desi -
- ovo ne može unutar jednog sql izraza, moraju se koristiti funkcije sql_table_update funkcije sa begin, end... i imati 2 poziva prema serveru
-
- ali to što si napisao ne radi u sql-u ...
-
- uh dobro si.
ovo uopšte ne vraća select -
- Ernad Husremović je napisao/la:
> napravio sam novi commit - stavio sam operaciju čitanja ids polja, update-a verzije semafora i nuliranja u jednu sql transakciju
> ...
ne kontam šta bi ovo trebalo da radi: -
- Saša Vranić je napisao/la:
> recimo, nakon ovog prvog test-a smo pokušali još dva puta
> ...
znači da nismo uspjeli reproducirati sa sigurnošću bug ! To nije dobro. -
- > zatim setuje/nulira IDS i setuje sa verzije 1104 -> 1106 svoju verziju i tom prilikom prazni IDS polje
> ...
ako stavimo sve bjasko operacije unutar jedne SQL trasakcije, bjasko bi morao vidjeti IDS i verziju onakvu kako je započeo tr... -
- napravio sam novi commit - stavio sam operaciju čitanja ids polja, update-a verzije semafora i nuliranja u jednu sql transakciju
provjeri samo da li je ispravna SQL sintaksa pa napravi gornje testove
-
- recimo, nakon ovog prvog test-a smo pokušali još dva puta
1) imamo isto stanje podataka, željka ažurira sa spavanjem -> ja radim opciju "R" -> sve ok na kraju
2) željka napravila jedan dokument, pa zatim pravi novi i u momemtu kada s... -
- ako u funkciju nuliraj_ids.... postavimo da prvo iščita šta ima pa da to logira, trebali bi da znamo šta je tu bilo prije nuliranja ids-a
-
- bjaskova trenutna verzija 1104, uzeo podatke IDS-a verzije 1105
zatim setuje/nulira IDS i setuje sa verzije 1104 -> 1106 svoju verziju i tom prilikom prazni IDS polje
zašto na 1106 ? zato što je željka završila svoju transakciju i sa 1... -
- Ernad Husremović je napisao/la:
> > bjasko je setovao na zadnju aktuelnu verziju 1106, umjesto na 1105 i praktično ispraznio svoj IDS (a bio je željkin dokument)
> ...
da, setovao je svoje polje version na 1106 (prema zanjem aktuelnom ... -
- h2. Momenti ponovo
> A u momenut čitanja podataka za bjaska:
> ...
Gornje pauze i testovi će izbaciti priču o "momentima".
Ovdje je glavno pitanje šta korisnik bjasko vidi, a šta ne vidi u periodu trajanja željkine transakcije. Narav... -
- > bjasko je setovao na zadnju aktuelnu verziju 1106, umjesto na 1105 i praktično ispraznio svoj IDS (a bio je željkin dokument)
šta je setovao ? svoje polje "version" u semaforima ?
Ja i dalje ne vidim to što govoriš.
To znači da je u... -
- > ovo je momenat kada bjasko u fakt_doks IDS nema ništa !!!!!!
a koju verziju semafora bjasko čita ? onu što je vzeljka postavila u transakciji ?
last_transaction_version je kako treba (željkino) ali ids je prazan (nema željkinih stavk... -
- Saša Vranić je napisao/la:
> sporan je dio čitanja podataka i nuliranja....
> ...
što će ga reći, preskočio je jednu verziju -
- praktično dio čitanja podataka nije zaštićen lokovima...
-
- sporan je dio čitanja podataka i nuliranja....
u momenut čitanja podataka za bjaska:
fakt_doks je bio verzija 1105 / uzeo je neke tada podatke
u momentu kada je bjasko radio NULIRANJE_IDS-a :
-> željka završila transakciju i setovala... -
- evo ga dakle, izvući ću samo bitan dio:
-
- ovako sam uradio:
vzeljka ažurira račun, kada se pojavila poruka "spavam" (traje 5 sekundi) ja sam pustio opciju "R"
nije mi javljala da je lokovano išta....
tom prilikom sam uočio samo sync fakt_fakt na dnu....
i kada sam odradio r... -
- > // bjasko setuje svoj "fakt_doks" na verziju 1094 (iako je željka setovala na 1095
> ...
bjasko u toku transakcije uopšte ne vidi željkine promjene - sve dok je transakcija u toku. on iz tabele čita 1094 last_version, a njegova versio... -
- takođe, svi useri su po okončanju transakcije morali imati ids-ove u fakt_doks od ovog spornog dokumenta ... to bjasko nije nikako mogao izbrisati, pošto je transakcija bila u toku ... tek nakon transakcije id-ovi su se trebali pojaviti ...
-
- Ernad Husremović je napisao/la:
> čitanjem gornjeg loga jedna stvar je nejasna - to su vremena
> ...
između free_tables i end_transaction je proteklo 3 sekunde. u tom periodu je jasko vidio verziju 1094 kao posljednu. Tako to i treba -... -
- h2. Kako ovo treba raditi
- lock obezbjeđuje da nijedan drugi user ne može vršiti pushiranje novih podataka
- na read operacije nema locka
u konačnici imamo:
# jedan korisnik samo smije pushirati nove podatke u tabelu
# svi korisnici m... -
- a nije nije... pardon to smo riješili
-
- obratiti pažnju na funkciju
* update_rec_server....
ona radi lock prvo, i ako je lock-ovano ona čeka i vrti.... i to je ok
kada se tabela unlock-uje, ona radi SQL_DELETE, SQL_INSERT i push IDS-ova na server....
A šta je sa po... -
- stavi na "liniju 260":https://github.com/knowhow/F18_knowhow/blob/a728578dd5a60baa21f409680bf56c68fafc7088/fakt/fakt_azuriranje.prg#L260
-
- Očekujem da ćeš od tri želkina ažuriranja svaki put moži uloviti u tih 5 sekundi da ti izmjenom fiskalnog računa "progutaš" fakt_doks.
Tek kada se to postigne slijedi rad na otklanjanju bug-a -
- bojim se da me ne razumiješ
nakon ovih linija stavi hb_IdleSleep( 5 sekundi)
time ćeš transakciju produžiti i na taj način ćeš moći bez problema reproducirati bug sa željkom. To očekujem -
- pogledaj,
https://github.com/knowhow/F18_knowhow/blob/a728578dd5a60baa21f409680bf56c68fafc7088/fakt/fakt_azuriranje.prg#L255
push_.... je unutar transakcije
gdje misliš da stavim ? -
- znači: naš slijedeći cilj je postići jednostavnu reprodukcija bug-a
-
- ovaj problem možemo dosta jednostavno reproducirati.
unutar fakt_azur funkcije treba staviti hb_idle ... jedno 5 sekundi nakon što se uradi push ids-ova.
Tako da namjerno usporimo transakciju ažuriranja. Time ćeš moći pri svakom a... -
- znači ovaj dio gdje bjasko radio DBF_SEMAPHORE_SYNCHRO mi uopšte nije jasan, zašto ga je radio ????
bjasko je setovao sa update_rec_server.... verziju 1094 i onda je radio i dbf_semaphore_synchro jer je utvrđeno da je kod njega verzij... -
- čitanjem gornjeg loga jedna stvar je nejasna - to su vremena
# vzelljka 12:10:37 - ver semaphore: 1095
# bjasko 12:10:39 - ver semaphore 1093->1094
# vzeljka radi free_tables 12:10:37
# ali ažuriranje dokumenta - SQL transakcije se zav... -
- > END: update semaphore version after push vzeljka last_ver= 1095"
treba dodati kod logiranja ime tabele
> ...
-
- evo momenta
-
- mislim sljedeće korištenje fakt_doks od strane bjasko usera
-
- > Opet fakt_doks nema ?!??????
dobro sada traži u logu sljedeći kontakt bjasko usera sa fakt_doks -
- Ernad Husremović je napisao/la:
> da li je u toku rada vašeg rada zastoja - lock situacija ?
jeste, ja sam puširao fiskalni račun i reklo mi je da je lokovano, pa je čekao da se tabela oslobodi i nakon toga update odradio -
-
- da li je u toku rada vašeg rada zastoja - lock situacija ?
-
- ok, testirali smo unos nekih 10-ak dokumenata
i na kraju imamo rezultat
* vzeljka ima sve dokumente i sve brojeve veze popunjene ispravno
* bjasko - fali mi dokument 10-10-00318, sve ostale dokumente imam
znači desio se neki ga... -
- napravio si grešku, ispravio sam
-
- smjestio sam CASE tamo gdje pripada - u "reset semaphores funkciju":https://github.com/knowhow/F18_knowhow/commit/b7d94088320b05b89204f981516c9768c717c44e
testiraj sada -
- pa dobro, praktično patch bi bio da se prije pokretanja na svim semafor tabelama odradi
-
- on je dobar workaround
-
- ipak je onaj moj CASE bio dobar :)
-
- ako za takvog recimo izbrišemo loko bazu i pustimo full sinhro, to će rezultirati greškom opet
-
- hoće li ovo ipak stvoriti problem na ostalim instalacijama ?
u svim tabelama koje nisu nikada pipnute u njihovom semaforu stoji -
- jeste, to sam ti gore rekao...
-
- pa da tu priču završimo pushirao sam commit koji sa prvim insertom u semafor tabelu stavlja status 'free'
Sigurno je default vrijednost kod kreiranja tabele semaphores stavljena 'full' u sql create skriptama -
- Ernad Husremović je napisao/la:
> Saša Vranić je napisao/la:
> ...
Ali da se više ne bi igrali nagađanja pogledao sam get_semaphore_status koja opet provjerava polje "algorithm" kako sam i pretpostavljao.
on jednostavno vraća njegov... -
- Saša Vranić je napisao/la:
> također, opet je problem jer već imam setovano u tabelama semafora da je last_trans_number = -1
> ...
testni scenario treba biti: nema zapis u fmk.semaphores_xyz i pobrisan dbf xyz
Dovoljno je da test ur... -
- Saša Vranić je napisao/la:
> pa imamo poslije ispitivanje semafor statusa i ako pročita "full" vjerovatno to ne zna hendlirati
mislim da to nije nikakav problem. Da jeste on bi davno iskočio
-
- pa imamo poslije ispitivanje semafor statusa i ako pročita "full" vjerovatno to ne zna hendlirati
-
- > da li je to ok ?
ako nije do sada pravilo probleme ne vjerujem ni da će sada.
koliko se sjećam to polje se prvo nije koristilo a onda se koristi za praćenje statusa lock/free.
Ovo je loša praksa (prekrivanje jednog sadržaja dr... -
- također, opet je problem jer već imam setovano u tabelama semafora da je last_trans_number = -1
i ovo sa 0 neće proraditi, sada bi morao proći i ručno opet izbrisati sve semafor tabele -
- hm.... ne kontam što je u algoritmu "full" ???
a onda sam skontao, kod prazne semafor tabele "full" je default vrijednost polja ako se ne setuje kod inserta
da li je to ok ?
znači desila se full sinhro ali se nije setovao semafo... -
- pokušaj sada pushirao sam tu promjenu
-
- ali jok !
treba u prvi insert staviti da je last_trans_verision = 0 ne treba nikakav greatest nakon toga -
- stavi ovako u sql statement:
-
- ili nešto slično.....
evo šta mi je ostalo nakon pokretanja u tabeli -
- kada se odradi full sinhro situacija u semaforu treba da bude
* za prazannu tabelu -
- nije ovo dobro, sada sam pobrisao sporne semaphores tabele da se inseruju friški zapisi, sinhronizacija prođe, ali kada ponovo uđem u aplikaciju opet mi radi full sinhro svih tih tabela, valjda zato što je -1
-
- > i kada počistim loko bazu i pustim krene full sinhro i ovdje izbaci grešku zato što ne može update da napravi, znači ne radi se o tome da nema zapisa u semafor tabeli, pa insert ubaci ovo gore što si stavio
testni scenario treba bit... -
- > znači ne radi se o tome da nema zapisa u semafor tabeli
insert NULL vrijednosti se dešavao kod dosadašnjih verzija. od sada će biti -1 i sve je onda riješeno.
-
- > kažem ti da u tabeli semafora već postoji zapis
odakle se taj zapis pojavio ? pojavio se insertom.
Izbriši ga pa će ga aplikacija ponovo kreirati
-
- pa dobro ali šta će mi INSERT ????
kažem ti da u tabeli semafora već postoji zapis
| version | last_trans_version |
| -1 | NULL |
i kada počistim loko bazu i pustim krene full sinhro i ovdje izbaci grešku zato što ne može updat... -
- ovo je moguće riješiti i tako da se u samoj tabeli kod kreiranja setuje default za last_trans_version = -1, i da se zabrani NULL vrijednost ovog polja.
Nije zgoreg to i učiniti kod nekog budućeg upgrade-a strukture baze
-
- vjerovatno još negdje ima insert into fmk.semaphores_ ... koje ja nisam našao to pronađi.
Tvoj case je bio workaround za loše setovanu vrijednost last_trans_version kod prvog inserta. nađi prvi insert
-
- pa onda nisam našao dobro mjesto gdje se dešava prvi insert.
treba njega naći i staviti -1 u last_trans_version
-
- da, ali opet na čistu bazu imam istu grešku "null value ...."
fazon je što u semaforima već imam ono gore stanje -1/NULL, znači zapis je već insertovan -
- tražio sam gdje se desi prvi insert u tabelu semafora pa sam tu stavio -1, a izbacio ovaj gore "CASE što si ubacio":https://github.com/knowhow/F18_knowhow/commit/afc41c45e257a1aebcb67fb2f34ce4bfc31d252b
-
- > ne znam šta u slučaju kada je NULL, čime treba da se puni
hm, 0 je vjerovatno ok, ali za svaki slučaj staviti -1 da se zna da se nije desila prva sinhronizacija ... ali u principu ovo se može izbjeći ako se kod prvog inserta stavi d... -
- > znači radim prvo pokretanje, kreiraju se baze i radi se full sinhro
ponovi situaciju prvog pokretanja nakon svih ovih ispravki koje si napravio.
potrebno je postići da se od prve izvrši inicijalizacija semafora i dbf-ova -
- postavio sam tako, evo sad ide
-
- trebalo bi nešto ovako ?
-
- a u tabeli imamo ovo:
| *version* | *last_trans_version* |
| -1 | NULL |
-
-
- također onda izgleda radi ovoga uđe u beskonačnu petlju i nonstop vrti osvježavanje te tabele iako je broj zapisa 0
-
- sad imam grešku
-
- ... i još ispravka bug-a "commit":https://github.com/knowhow/F18_knowhow/commit/5a15466db034081143bffd9be9b299a4c3e96455 u sql klauzuli
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/46e25824db5f65a507951306b34ab98fb0b707d0
napravio fprint test režim rada
ispravio bug u update_semaphore... funkciji -
- još "cleanup-a":https://github.com/knowhow/F18_knowhow/commit/d70a0118abfc80eeb048d93578cb98767f54441a update semaphor funkcije (ovaj i još jedan parent commit).
Sada je to funkcija koja se koristi samo nakon push operacije. Nakon read ... -
- ok, idem to napraviti
-
- Hajde molim te testiraj ovo sa željkom.
Podesite rad na testnom serveru (to je jasko osposobio) ili neka se ona zakači na tvoju testnu sesiju. pa simulirajte jučerašnje operacije.
Isprovocirajte gubitak stavki u fakt_doks.
Što s... -
- ovo je još pametnije "setovanje verzije nakon nuliranja":https://github.com/knowhow/F18_knowhow/commit/0e6451ea845c8d939966581aae109460228778e6
nemam potrebu čitati last_version u predhodnom statementu - jednostavno setujem ono što za... -
- bilo je dosta dupliranja i nepotrebnog koda.
update_semaphore funkcija se pozivala na duplo kod operacija čitanja
h2. Trenutak nuliranja semafora, rad drugih korisnika
takođe je bilo provjeravanja statusa semafora za tabelu kod ... -
- uradio sam "rewrite update_semaphore_version funkcija":https://github.com/knowhow/F18_knowhow/commit/259b6922f09e2b396cf40fe2b65e30f63695a3b8
to je ovaj i još 3 commit-a.
21.11.2012
-
- evo loga današnjeg da ima
-
- da.....
imamo update_semaphore_version() poziv u
nuliraj_ids.... funkciji
i u funkciji
ids_synchro() -
- Ernad Husremović je napisao/la:
> pogledaj koliko rupa ima u mojoj listi dokumenata.
> ...
griješiš samo ti *fakt_doks* nije bio sinhronizovan, zato što si štampao fiskalne račune, *fakt_fakt* ti je bio korektan
ako si štampao račun... -
- kada kažeš *transakcija* trebaš biti precizniji - misliš na traksakciju čitanja ili transakciju pisanja podataka.
generalno, unutar transakcije se dešava samo pisanje podataka.
Misilm da veliki broj rupa u mojoj listi nije uzrokova... -
- i kod željke se 2 puta okinulo
-
- pogledaj koliko rupa ima u mojoj listi dokumenata.
tu se definitivno ne radi ni o kakvom bugu uzrokovan milisekundama - kod mene nije bilo u listi sinhroniziranio 4-5 dokumenata.
Bug je definitivno golem ko kuća, ali ga ne vidimo -
- da to je to, nuliranje, pokupio sam set, ali je u međuvremenu uletio novi ID i jednostavno sam ga obrisao kada sam završio svoju transakciju
-
- hm... ili možda onaj bug koji sam predvidio ranije na #29539
a to je ovaj komentar http://redmine.bring.out.ba/issues/29539#note-64 -
- > interesantno je to zašto u hernad transakciji nema NULIRAJ_IDS
nuliranje se izvrši nakon što se preuzmu id-ovi sa servera - iz semafora.
Nuliranje se ne vrši prilikom pushiranja novih podataka na server. -
- Moguće s obzirom da nije bilo prijava drugih korisnika ...
Ovakav način rada - jedan fakturiše, a drugi pravi fiskalne račune samo mi prakticiramo. Taj scenario očigledno reproducira bug -
- interesantno je to zašto u hernad transakciji nema NULIRAJ_IDS.... ?!?????????
kada radim update, praktično mjenjam broj verzije IDS-a ? zar ne bi trebao nulirati
kao da je to problem u funkciji *update_dbf_server_and_dbf* -
- praktično željka je krenula sa update-om podataka verzije *1416*
u tom momentu je hernad uletio sa setovanje broja veze i napravio verziju *1417*
i željka završava svoju transakciju sa verzijom *1417* ali nije uspjela dabiti u dbf ... -
- znači postoji problem, naznačio sam ga kao BUG u ovom transkriptu log-a gdje je podatak izgubljen
-
- sporan je račun 10-10-00424, za njega nije osvježen broj fiskalnog računa kod vzeljke
evo dijela log-a -
- bilo je 4-5 faktura koje nisam vidio dok nisam uradio full sync.
Pogledaj rupe u brojevima u ovoj listi http://redmine.bring.out.ba/issues/29641#note-23
-
- koji ti je hernad dokument bio sporan ? koja faktura pa je nisi imao
-
-
-
- ma ovo je taman prilika da se pretrese i unos fakt dokumenta, to je ostalo dosta zapušteno
-
- ... ali je tu lahkoću teško postići ako se sve u cjelini "ne pretrese" - mislim na koncept svih pripremnih tabela.
-
- međutim, ako se atributi smještaju na server onda nema smisla da se i ostale stavke ne smjeste na server.
Naime, ima smisla sve podatke u slučaju izlaska iz pripreme prebaciti na server ...
Ali onda dolazimo do potrebe za pripremnim d... -
- Saša Vranić je napisao/la:
>
> ...
možeš poslati na server prije izlaska iz aplikacije ili iz pripreme fakt.
u slučaju brisanja pripreme - pobriši atribute i to je teo.
tabela neka se zove fakt_fakt_atributi
-
- Ernad Husremović je napisao/la:
> Saša Vranić je napisao/la:
> ...
hm... da ali ako izađem iz pripreme ode sve u hendek :) ili izađem iz aplikacije a dokument ostane u pripremi
-
- Ernad Husremović je napisao/la:
> nikakvo budalesanje c_1, c_2 nam ne treba
> ...
da da, to je bolje -
- nikakvo budalesanje c_1, c_2 nam ne treba
primarni ključ tabele je četvorka (idvd, brdok, rbr, atribut) -
- fakt_opis tabela treba izgledati ovako
fakt_opis(idvd, brdok, rbr, atribut, value)
tako recimo stavka 2 dokumenta 10-0050 ima LOT = 122 i REF = R125
=>
fakt_opis(10, 50, 2, "LOT", "122")
fakt_opis(10, 50, 2, "REF", "R125")
... -
- Saša Vranić je napisao/la:
> jedino još ne znam kako uvesti ovu tabelu, da li raditi semafor ili samo napraviti
> ...
da li nam temp tabela uopšte treba ? Ove podatke jednostavno možemo držati u memoriji tokom pripreme naloga kao array s... -
- zrakni i ti pa vrati
-
- jedino još ne znam kako uvesti ovu tabelu, da li raditi semafor ili samo napraviti
_fakt_opis.dbf
(pripremnu tabelu)
koja će se puniti i na osnovu koje ćemo puniti server tabelu itd... -
- ovo je garant nešto do podešenja wine-a
-
- unutar delphirb-a se vrši
-
- za delphirb u fmk.ini fajlu postoji i podešenje konverzije
-
- recimo na windows stanici radi...
vjerovatno encoding zapisa
ne znam da li je jedino moguće da je pogrešno setovanje wine instance - ima li ona encoding, kao da sam ranije vidio da negdje to i radi ?!!! -
20.11.2012
-
- nisam skontao opet ovaj prelom....
za sada napravio 2 fajla pa se određuje koji će se pozivati. -
-
-
- Da bi ovo odradili, defakto je potrebno logirati se na XTUPLE pa kroz user kontrole odobriti korisnike i setovati im ime i prezime itd....
lakši način je kroz sql konzolu, ako zadamo sljedeće komande (primjer prikazuje komandu za jed... -
-
- HCP funkcije testirane...
FPRINT funkcije testirane....
uživo na uređajima -
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/058a41e03ad400096adcb0c1349489bb3ad6b3d1
-
- ispravljeni template fajlovi
"F18 template 1.2.6":http://code.google.com/p/knowhow-erp-f18/downloads/detail?name=F18_template_1.2.6.tar.bz2&can=2&q=
napravljena nova verzija koja sada omogućuje štampu kartica
* jedna kartica
*... -
19.11.2012
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/bb7a3794b8f6bf7c7560d354a80fd9cd572443cb
napravljen template i napravljena štampa u odt formatu...
moram skontati još ovaj PAGE BREAK definitivno -
- xml struktura je ovakva....
-
- ostao je još ODT print podataka
-
- kod velikih podataka (baze) na meniju uvedena opcija "generisanje podataka..." a onda prilikom poziva IOS izvještaja isključimo opciju "automatski generiši podatke IOS-a..."
-
- ok, postojeća txt varijanta stavljena u funkciju...
nije potrebno raditi generisanje podataka itd... to se uradi automatski kod pokretanja izvještaja i više se ne vrši unutar funkcije IOS specifikacija, to je sada čisto izvještaj.
-
- odmah sam predvidio i opciju štampe kroz ODT format...
-
- Ovako, prvo nepotrebna šuma koda sa opcijama
* pojedinačni
* svi
sve opcije koriste istu stvar, samo je pitanje da li ćemo zadati partnera ili ne !
"commit":https://github.com/knowhow/F18_knowhow/commit/7d6442d0e27a73c1582c1461... -
- postoje izvjesni problemi sa ios-om tako da sam uzeo ovo da malo sredim...
-
- provjera naziva artikla, centralizirano
"commit":https://github.com/knowhow/F18_knowhow/commit/269e98434e37a6ff82102b599370bf27712d993d
recimo kod FPRINT-a ne smije biti znak ";" -
- "commit":https://github.com/knowhow/F18_knowhow/commit/da96361f0a255e958879abaebffa5b29f0b07694
provjera izlaznog direktorija prije štampanja fiskalnog računa
16.11.2012
-
- ... i mislim da sam pročistio, testirao sam sve fiskalne opcije
* fprint, tremol
* hcp nisam, tu imamo nekih kamaru fajlova...
Treba odmah predvidjeti i onu provjeru lokacije koja nas je zezala... ono nije drive dostupan i slično. -
- uklonio potpuno tabelu fdevice.dbf itd... stare opcije
"commit":https://github.com/knowhow/F18_knowhow/commit/acd71aa838208f011b3e4a349e4a0be88e31ad77
sređene funkcije ispisa i unutar POS-a -
- očistio sam dosta fiskalnih funkcija, ima toga još...
recimo objedinjena je funkcija koja vraća oznaku tarife za txt/xml fajl
isto treba odraditi za vrste plaćanja, jedinice mjere... -
- prije je to svaka funkcija radila sama za sebe
-
- do kasno sam radio na ovim opcijama...
uspio sam konačno da objedinim sve, što znači opcija štampe fiskalnog računa iz modula FAKT teče ovako: -
- h1. 4) Odabir uređaja prilikom izdavanja računa
Prilikom izdavanja fiskalnih računa dobit ćemo menij
!scr_05.png!
iz kojeg ćemo izabrati aktuelni uređaj na koji želimo pustiti račun.
*Napomene:*
* Ako je podešen samo jedan... -
- Fiskalne uređaje ćemo podesiti na sljedeći način:
h1. 1) Podešavanje fiskalnih uređaja unutar preduzeća
Odaberemo fiskalne parametre sa menija prametara (nisam postavio mjesto gdje se nalaze, jer su još u fazi izrade) te dobijamo... -
-
15.11.2012
-
- Ovo
Fi. novi parametri
je privremeno, neće tako biti... između ostalog to će biti samo F. ali nisam još isključivao trenutnu fiskalne parametre -
- uočio sam još radnije da na opcijama menija stavljaš dvoslovne oznak oznake tipa:
* "1. opcija"
* "F. Francuska"
* "Fi. Fiskalni parametri"
* "10. opcija deset"
To nije dobro. Meni je osjetljiv na prvo slovo tako da se opcija Fi ili 10... -
- "commit":https://github.com/knowhow/F18_knowhow/commit/5570ac226018e26cb767050e18423caf9c396650
napravio sam niz izmjena, uveo parametre itd....
sada trenutno radim na revrajtu opcija fiskalne štampe... itd...
ovo će mi trebati ...
14.11.2012
-
- i to bi trebalo da proradi sve...
Ništa, prvi korak je uvođenje funkcija za podešavanje i čitanje parametara...
*Setovanje:* -
-
- ovim uvođenjem bi se i masa onih globalnih parametara riješila, tj. nema potrebe za njima...
sad imamo ono gFisc_use, gFisc_type itd...
a sada bi se kod fiskalnih opcija samo proslijedio "id uređaja" i automatski bi se iščitale pos... -
- h2. Fiskalni uređaj prema vrsti dokumenta
I ovo je bitna stvar, da mogu podesiti da mi sve 10-ke iz FAKT-a idu na uređaj 1, a 11-ke idu na uređaj 2
Da li ovo može biti globalno ili može biti od korisnika do korisnika, hm...
* us... -
- pošto nemamo mogućnost brisanja parametara onda možemo predvidjeti odmah 10 uređaja
uređaj 01 -
- dolazimo do ovakvog seta podešenja:
*fiskalni parametri*
# globalni fiskalni parametri
# podešenje uređaja
# podešenje korisničkih postavki
# pregled tekućih postavki
gdje su:
h2. 1) globlani parametri
* koriste li se... -
- Ono što je upitno je kako setovati ove parametre, znači imamo 2 nivoa setovanja parametara...
# štimanje uređaja (globalni parametri)
* uređaj_id
* naziv
* tip
* iosa
* itd...
# štimanje korisnički parametara za sam uređaj
* korisnik_i... -
- h2. Auto generisanje PLU kodova
Na osnovu ovih parametara mi praktično uvijek imamo ID definisanog uređaja, (1, 2, 3, ... )
Pa tako, taj id proslijeđujemo funkciji koja se brine za automatski PLU. -
- praktično na nivou preduzeća bi trebali da definišemo uređaje
preduzeće: *f18_01* (to je baza)
u njemu se koriste 3 fiskalna uređaja
definišemo u parametrima -
- Kod ovih opcija se treba obratiti pažnja na automatsko generisanje PLU kodova, to je parametar u pgsql-u.
Tako da smo recimo imali situaciju da ista baza (više korisnika) pristupa na svako svoj uređaj.
Znači imamo 2 radne stanice:
... -
- Imamo tri vrste rada sa uređajima:
h2. 1 situacija
Jedan korisnik i jedan fiskalni uređaj (standalone instalacija)
h2. 2 situacija
Više korisnika i više fiskalnih uređaja
h2. 3 situacija
Više korisnika i jedan fiskalni ... -
- Prije svega je potrebno analizirati ovu situaciju...
-
- Jučer usmeno pričali oko ove teme, pošto se pojavio problem u situacijama gdje se koristi lista uređaja, tj. da sa jednog radnog mjesta možemo slati račune na više fiskalnih uređaja i različitih tipova.
-
-
- vrlo jednostavno u ovu tabelu možemo dodati i proizvoljna polja, kako je to bilo u FAKT.DBF tabeli:
* c_1
* c_2
* c_3
* c_4
* c_5
itd...
tabela: *fakt_opis*
| *idfirma* | *idtipdok* | *brdok* | *rbr* | *opis* | *c_1* | *c_2* | *c_3* ... -
- praktično nama treba tabela koja će sadržati neke dodatne opise i karakteristike po stavkama fakture...
recimo, ovaj tiket je vezan za opis, ali imamo recimo i ona polja:
* serijski broj
* lot broj
* ref broj
* itd...
znam d...
12.11.2012
-
-
- postavljeno kod ažuriranje, prenosa... prenosa kalk->fin itd..
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/beb0b94eceaa23c11d18db2cdf1b99e4fe7f798e
globalni brojač stavljen u funkciju -
- "commit":https://github.com/knowhow/F18_knowhow/commit/a7f4e5f93c9a7ae1ad46124eed83f37714069976
prenos podataka za lisec, fmk korigovan, očišćen od bug-ova
08.11.2012
-
- ove sam uzeo iz xtuple updater-a 2.2.4
-
- preljepimo preko trenutnih i stvar proguli
-
- ista stvar kao i u rudniku bila, W7 updater ne funkcioniše, nadošao da je problem do dll-ova
-
- jednostavno, ovakve konekcije na redmine mogu trebati i za druge stvari i za druge module
-
- nisi trebao zatvarati ovaj tiket svejedno...
napravio sam redmine biblioteku
"f18_redmine.prg":https://github.com/knowhow/F18_knowhow/blob/54e5fba9a67f17ae135cf66e9fdcc5004b857197/common/f18_redmine.prg
koja se koristi na sljedeći nač... -
- tako sam u biti i implementirao...
to su parametri koji se koriste sa set_metric ili fetch_metric
-
- vidim da sam i ja pominjao http://redmine.bring.out.ba/issues/29110#note-8 login formu, što je pogrešno - tačnije nepotrebno.
-
-
- znači *NE* džoniti login formu postgresql-a, nego jednostavno definisati parametre konekcije na redmine bazu podataka.
Parametri, globalno za organizaciju:
# redmine_db_type: mysql
# redmine_db_user: root
# redmine_db_password: redmine... -
- to riješiti putem parametara u RNAL-u.
Nema potrebez za pravom interaktivnom login formom. -
- Pored postojeće login forme koju imamo, treba implementirati i formu za konekciju na mysql bazu
tako da prije pokretanja specifičnog izvještaja imamo "podesiti parametre konekcije"
gdje će se otvoriti forma sa parametrima za kačenje na... -
-
- puširao windows 32 verziju
-
- puširao template 1.2.3 verziju
puširao ubuntu32 verziju F18
-
-
-
- ako je ovaj parametar popunjen pri unosu fakture se ispisuje stanje tog artikla
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/645ddc3690811cebe1d9db0184136395b4374678
-
- postavimo za RJ 10 - konto 1330, za RJ 11 - konto 13301 itd...
po želji -
- U FAKT-u u šifrarniku radnih jedinica je potrebno postaviti za odgovarajuću radnu jedinicu koji će se konto gledati
-
- napraviti ovo danas
-
-
- greška:
-
-
07.11.2012
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/09eeb851b7435e3b7c2b122f639c278f4c5ab25e
-
02.11.2012
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/e04367675e5afd3e3cdce4086fb14fec1bc2910e
ispravljeno -
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/e04367675e5afd3e3cdce4086fb14fec1bc2910e
zatvore se tabele pa se otvaraju iznova -
- Opcija inače radi, ali najvjerovatnije kada povučemo neki izvještaj ili slično nešto bude sa tabelama.
-
-
- ako ostane u nekoj fazi crven na kraju to nije dobro i to je sam indikator da nešto nije ok.
-
- pored što se logira napravio sam da se ispisuje stanje u donjem dijelu aplikacije, kao i nivo logiranja
"commit":https://github.com/knowhow/F18_knowhow/commit/d7e7374604e8710ede0fe1a5e048492150bd8dd0
i to sada lijepo vidimo, recimo... -
- Ovo nije loša stvar da se vidi stanje semafora
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/a3d194b4398e32af7a129ec9d753d9bb5ee60edc
i to se sada logira, to je recimo također jako bitno kod pregleda log-a -
-
-
- recimo funkcija (sestra) delete_rec_server_and_dbf... to radi
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/440bd3e6d951878eb236dcf0f05470c3b3a4de90
-
-
- ako fali šifra javnog prihoda aplikacija izbaci error sa funkcijom
-
-
- lažna uzbuna
-
01.11.2012
-
- h2. rezime f18 core library ver 3.7.7
Po završetku f18_lock_tables funkcije sve dbf tabele koje su sinhronizovane, ostaju otvorene u svom standardnom području
Prije poziva f18_lock_tables nije potrebno otvarati te dbf_ove
-
- ovom ispravkom se obezbjeđuje da će dbf tabela koja se lockuje biti otvorena:
https://github.com/knowhow/F18_knowhow/commit/20dba1dd32b02db63f7eb1b1213d2e23b3bb7def#L3L62
i pri tome biće otvorena u svom standardnom području (WA) -
- u pravu si da bi close all u f18_lock izazvao haos.
ali ni ovo tvoje rješenje nije dobro. ostaje na istom kao juče.
Zašto nije dobro ? zato što iza f18_lock ne znamo kakvo je stanje, a to je veliki problem.
Na svim mjestima gdje... -
- korigovao sam ovo isto i kod KALK, FIN modula
isključio one my_use_semaphore sekvence -
- recimo, testirao sam fakt ažuriranje na dvije strane i to radi kako treba
fino sinhronizuje podatke itd... nisam imao nikakvih propusta -
- ovi koraci koji su planirani će napraviti budaleštine a to nam ne treba na terenu
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/18b6079931176a4670021ed2153b26aeab6a70ad
ja bih za početak napravio ovako:
recimo fakt ažuriranje
https://github.com/knowhow/F18_knowhow/blob/18b6079931176a4670021ed2153b26a... -
- I to će stvoriti belaj !!!
Trebalo bi onda unutar funkcije *f18_lock_tables* da se desi -
- h2. 2) Update pojedine stavke u tabeli
Evo jednog lijepog primjera
https://github.com/knowhow/F18_knowhow/blob/7b95a882381d725a3d8319aa399e39bde7f7b404/fakt/fakt_fiscal.prg#L1375
update broja fiskalnog računa
ovdje korisimo F... -
- međutim to će ostaviti efekta na dosta stvari
imamo recimo:
# ažuriranje
# update neke tabele
h2. 1) Ažuriranje
Ovo je jasna situacija, nako što se pozove -
- sada smo usmeno dogovarali da treba da se u f18_lock_tables() funkciju uvede da nakon što se osvježi stanje da se zatvore sve tabele
-
-
-
- parser uvijek mora dati rezultat, ne smije provjeravati da li je uslov prazno
ako nam treba takva vrsta provjere onda radimo ovo: -
- "commit":https://github.com/knowhow/F18_knowhow/commit/3cd0ebb0ed3036ab5764d6cd00efe64054ea2bc7
ispravljeno -
- prilikom pregleda jednog log-a uočio sam ovu grešku
-
-
- implementirana opcija brojača
"commit":https://github.com/knowhow/F18_knowhow/commit/de1f958e533cda8bc294c6248cdacbf7c463a418
tj, glavne funkcije
sada ih treba ubaciti unutar novog naloga itd....
gdje god ima potreba za tim -
- imamo ove prenose KALK->FIN itd... i u tim momentima brojači se dodjeljuju putem dbf-a, kao do sada...
treba uzimati globalni brojač sa servera -
- implementirati identičnu stvar kao i u modulu FAKT, brojač treba da se uzima sa servera
-
- nisam upratio ovo, izbacuju se totali na izvještaju
-
-
-
- ispravljen bug kod ručnog unosa zaduženja
"commit":https://github.com/knowhow/F18_knowhow/commit/753c725b88ef1414ef7a984fa6bac5ddda6e36c4
-
31.10.2012
-
- Ernad Husremović je napisao/la:
> nema potrebe za ovo _std u naslovu
> ...
to je stavljeno iz razloga što može biti druga varijanta kartice, pa bi bio fin_kart_02 ili nešto treće -
- na ticket staviti uzorak izvještaja.
sam template izbriši sa ticketa -
- nema potrebe za ovo _std u naslovu
staviti "fin_kart"
-
- template smješten unutar paketa 1.2.2
http://code.google.com/p/knowhow-erp-f18/downloads/detail?name=F18_template_1.2.2.tar.bz2&can=2&q=#makechanges -
- može se koristiti
-
- i eksport kartice vratio u funkcionalnost
-
- ispravljeni i datumi, ubačena i mogućnost dvovalutne kartice itd...
sada je to kompletno -
- "commit":https://github.com/knowhow/F18_knowhow/commit/4bf7a0b4bf7856ceb24f7279f291313fb642e315
ubačena varijanta, bez datuma, sa jednim datumom ili datum prazno itd...
30.10.2012
-
-
- puširao windows32 verziju
-
- puširao ubuntu32 verziju
-