Podrška #25077
Zatvoren
brojači dokumenata
30%
Povezani tiketi 4 (0 otvoreno — 4 zatvorenih)
Izmjenjeno od Ernad Husremović prije oko 13 godina
ovo treba odmah prebaciti na serverside procedure
NoviBrNal(cBrDok) treba da poziva server view.
Brojač naloga može biti postgredsql sekvenca ili polje unutar fmk_semaphores_fin_suban ... fin_nalog ....
vidjeti šta je najbolje rješenje
Izmjenjeno od Ernad Husremović prije oko 13 godina
- Prioritet promijenjeno iz Normalan u Urgentno
Izmjenjeno od Ernad Husremović prije oko 13 godina
- Odgovorna osoba promijenjeno iz Ernad Husremović u Saša Vranić
ovo se može uraditi na dva načina:
1) prije utvrđivanja broja osvježiti tabelu koju pretražujemo sa my_use
2) napraviti serverside proceduru
ovo pod 1) je jednostavno odmah riješiti.
Pod 2) je kvalitetnije rješenje.
Izmjenjeno od Saša Vranić prije oko 13 godina
dakle, samo ovako pozovemo my_use() kako sam shvatio
https://github.com/knowhow/F18_knowhow/commit/8718c95c45e2fb64e9292ebf1bfad63e8e6e204d
Izmjenjeno od Ernad Husremović prije oko 13 godina
ti na već otvorenu bazu radiš novi my_use
trebaš zatvoriti pa otvoriti. s obzirom da je u O_NALOG već sve to smješteno
radiće
select F_NALOG use O_NALOG ....
ovo što si ti uradio je u najmanju ruku sumnjivo. vjerovatno nije dobro.
Izmjenjeno od Ernad Husremović prije oko 13 godina
ali svakako nema nikakvog smisla da to radiš ovako.
napisao sam kako se testira, za ovakvu opciju nema smisla nabadati - testiraj.
Izmjenjeno od Saša Vranić prije oko 13 godina
Ovo je testirano i radi ovako kako je zamišljeno, ali:
ovo nema veze s vezom, ono što nama treba je da kada korisnik dobije broj da to bude taj broj.
Recimo kod naših korisnika ovo će biti bezvrijedno... trenutno je situacija takva da se dešava ovo:
- pravim novi dokument
- štampam iz pripreme - u tom momentu u tabeli DOKS na serveru zauzimam dokument i zapis u tabeli
- ažuriram dokument - dešava se UPDATE tabele DOKS i INSERT u tabelu FAKT
na taj način je obezbjeđeno da svaki korisnik dobije svoj broj dokumenta i da nema podudaranja.
U ovoj sitaciji imamo sljedeće:
- korisnik 1: pravi dokument - dobija od servera sljedeći broj
- korisnik 2: radi isto i dobija isti broj
- korisnik 1: ažurira dokument - ok
- korisnik 2: server ga odbija - DUPLICATE KEY
znači, od ovoga ništa...
na serveru treba da se zauzimaju brojevi...
Ja ne znam da li sa transakcijama to možemo da riješimo
- BEGIN
- INSERT fakt_doks (set br_dok)
- ... pravim dokument
- UPDATE fakt_doks
- END
a fakt_fakt ide regularno
- BEGIN
- INSERT
- END
Izmjenjeno od Saša Vranić prije oko 13 godina
ovoga imamo praktično u svakom modulu FIN, KALK, FAKT, RNAL (pogotovo) on je sav ovakav...
Izmjenjeno od Ernad Husremović prije oko 13 godina
na serveru treba da se zauzimaju brojevi...
to niko ne radi.
Pogrešno pristupaš problemu. U epdv-u je stvar drugačije rješena. Broj se dobija pri ažuriranju. Tačka.
To je ispravan pristup. Sve stvari kao što je zauzimanje brojeva je nepotrebno komplikovanje i pravljenje nauke od nečega što je jednostavna stvar.
To neko zauzimanje je moguće putem semafora. Ali ne pada mi na pamet da ulazimo u to.
Kada se bude rješavalo treba to riješiti čestito a ne preslikavanjem pogrešnog koncepta iz FMK.
Izmjenjeno od Ernad Husremović prije oko 13 godina
dokument do ažuriranja treba da nosi ime:
10 - 10 / PRIPREMA / user / DATUM
a ne 10-10-neki_neizvjesan_broj
Izmjenjeno od Ernad Husremović prije oko 13 godina
da bi se što više ostavila ranija praksa ovo je rješenje:
kada se kreira dobije broj je aktuelan
10-10-00030 PRIPREMA / user
(možemo čak povremeno i checkirati ovaj broj ... prije štampe recimo ga osvježiti ako je zastario
Na kraju kod ažuriranja:
- checkiramo broj, ako nije svjež dajemo novi
- nakon uspješnog ažuriranja nudimo ponovno štampanje konačne verzije dokumenta. samo na ažuriranom dokumentu nema oznake "PRIPREMA"
Izmjenjeno od Ernad Husremović prije oko 13 godina
takođe možemo uvesti 0000 za broj koji praktično kaže - nije dodjeljen broj.
Izmjenjeno od Saša Vranić prije oko 13 godina
- Odgovorna osoba promijenjeno iz Saša Vranić u Ernad Husremović
Izmjenjeno od Ernad Husremović prije skoro 13 godina
- Prioritet promijenjeno iz Urgentno u Odmah riješiti
osmisliti nešto univerzalno ovo je bitan problem u višekorisničkom radu
Izmjenjeno od Ernad Husremović prije više od 11 godina
- Status promijenjeno iz Dodijeljeno u Zatvoreno