Odredjivanje broja dokumenta u multiuser okruzenju

Jednostavno pitanje.
Aplikacija u VB-u, baza podataka mdb. Prave se racuni na dve pckase. Koji je najpouzdaniji nacin da svaka kasa izabere broj racuna a da ne dodje u konflikt sa drugom kasom. Broj racuna je primarni kljuc, ne moze se duplirati, naravno.
Imam dve ideje:
1. (jedna koristi SELECT MAX(BrRac) FROM Fakture) - spora kod velikog broja slogova u tabeli
2. koristi posebnu tabelu gdje su podaci o broju poslednjeg racuna, koja se updatuje

Da li je ovdje potrebno pesimisticko zakljucavanje sloga (LockPesimistic), i koliko ono garantuje da ce se konflikt izbjeci? Kako kod ovog drugog obezbijediti takvu transakciju da ako snimanje podataka ne uspije da se ponisti i promijena poslednjeg broja racuna?

Hvala unaprijed

Nisam te najbolje razumeo ali meni je najlogicnije da postavis jedan indikator koji govori sa koje je kase racun. Time postizes da mozes svoju aplikaciju da prosiris na vise od dve kase u buducnosti.......

Pretpostavljam da imas tabele tblRacuni i tblDetaljiRacuna. Posto je FE VB, ima mnogo nacina da se resi unos u kasu. Zato nam moras dati vise detalja. Opisi nam proces kreiranja racuna - kako tacno treba da izgleda dogadjaj na kasi. Na primer: kupac dolazi na kasu da plati. Sta radi kasir? Sta kuca? Kojim redom se ubacuju rekordi u tabele tblRacuni i tblDetaljiRacuna (svakako prvo rekord u tblRacuni, pa onda u tblDetaljiRacuna). Da li se sve prvo unes u neke lokalne tabele pa onda preseli u bazu podataka, ili radis kao sa Access form-subform strukturom, pa sve ide direktno u tabele?

Samo su dve tabele. U jednoj smjestam sve podatke o racunu (primarni kljuc mi je slozenog tipa=BrojRacuna,RedniBrojStavke,SifraObjekta), u drugoj sve podatke o Otpremnici koja se pravi u pozadini.
Ne znam zasto je moje pitanje nejasno. Kad vise kasa istovremeno snima podatke u glavnu bazu (svaka kasa ima privremenu tabelu tako da ako se odustane od izrade racuna u glavnu bazu se nista ne snima), moze se dogoditi da dvije pokusaju unijeti racun sa istim brojem. Mene zanima ima li neko iskustva koja tehnika daje najrjedji slucaj kolizije. Ja imam odradjenu obradu greske, ali nekad se desi da snimanje kod jedne strane ne uspije - previse cesto za moj ukus.

Slusaj, pitanje nije jasnio jer nam ne kazujes nista konkretno. Sam sam morao da zakljucim da imas dve tabele. Sam sam morao da zakljucim da mozda imas pribvremene tabele, za svaku kasu. S obzirom da radis u VB, gde ti sede te privremene tabele? Ne kazes nam kako se zovu i u kakvoj su vezi glavne tabele. U kakvoj je vezi Otpremnica i racun? Gde ti se vidi koja kasa radi na kom racunu? Kog tipa ti je polje BrojRacuna? Kako se dodeljuje (to je tvoje pitanje?). Tvoja aplikacija ocigledno radi u nekim uslovima, a zaglavi u nekim drugim uslovima. Reci nam kako radi kad je sve OK, a onda nam reci kad nastaju problemi.

Nemoj da se ljutis, ali te stvarno ne razumemo. Nismo ni glupi ni nestrpljivi, pa pokusaj da budes jasniji. Pomoc treba tebi, a ne nama. Da te je neko razumeo, vec bi verovatno dobio odgovor.

Pa ne znam sta da kazem. Mene samo interesuje da cujem nekog strucnjaka za Jet engine u multiuser okruzenju kako rjesava konflikte prilikom insertovanja novih stavki u neku tabelu. Ja se vama zahvaljujem na spremnosti da pomognete, ali mislim da sam bio dovoljno jasan za nekog ko se razumije u ovu materiju, bez uvrede. Naveo sam vam sta cini primarni kljuc kljucne tabele, a kase rade jednostavan posao: barkod čitačem se unose stavke u privremenu tabelu, a onda se pritisne jedno dugme koje pokreće štampanje računa i prebacivanje podataka iz privremene tabele u glavnu. Posto to isto istovremeno radi vise kasa, htio sam cuti nekog iskusnijeg kako rjesava eventualne konflikte tipicne za multiuser okruzenje. Posto su kase samo dio jednog veceg sistema koji puni jedinstvenu bazu, potrebno je u pozadini napraviti i otpremnicu koja sa primkama i medjuskladisnicama tvori podlogu za pracenje materijalnog knjigovodstva, stanja zaliha, detektovanja kriticnih kolicina i td. Ja u jednoj transakciji pravim i otpremnicu i fakturu (prebacivanje iz temp u glavnu tabelu), tako da ako jedna ne uspije, ponistavam cijelu transakciju. Sve tabele su u jednoj bazi, na jednom racunaru u lokalnoj mrezi od ukupno cetiri računara.

Ti ocigledno ne mozes ili neces da komuniciras. Postavio sam ti nekoliko pitanja:

"S obzirom da radis u VB, gde ti sede te privremene tabele? " - bez odgovora

"Ne kazes nam kako se zovu i u kakvoj su vezi glavne tabele. U kakvoj je vezi Otpremnica i racun? " -bez odgovora

"Kog tipa ti je polje BrojRacuna? Kako se dodeljuje (to je tvoje pitanje?). " -bez odgovora

"Reci nam kako radi kad je sve OK, a onda nam reci kad nastaju problemi." - bez odgovora

Ima mnogo nacina da se dodeli PK prilikom inserta, a koji je najbolji za tvoju situaciju, zavis - od situacija. Ja razumem da ti odlicno razumes svoj problem, ali ocigledno je da niko drugi ne razume. da neko razume, vec bi dobio odgovor. na ovom forumu ima narem 5 soba koje garantovano znaju da to odrade ali ne maju dovoljno poadataka da bi ti dali ispravan odgovor.

Ovo je forum za Access i u Accessu se tvoji problemi resavaju na potpuno drugi nacin tako da uopste ne postoje kao problemi.

Mozda da probas na VB forumu? Znas kako kazu, Access je za neozbiljne projekte, za ozbiljne stvari napravi front end u VB sa back end u Accessu. Siguran sam da na VB forumu ima mastora koji ce te razumeti iz prve i naci odgovor za tvoju muku.

Izvini, ako sam na neki nacin nekog uvrijedio, nije mi bila namjera.

je odgovor na pitanje gdje su privremene tabele (ja ih sam kreiram sa CREATE TABLE - nisu one TEMPORARY od Accessa), dakle sve tabele su u istoj bazi.

Otpremnica i račun nisu u nekoj vezi u smislu da su povezane nekim referencijalnim integritetom (tj. da su u relaciji jedna s drugom direktno). Jednostavno, kako sam već rekao, otpremnice su dio tabele koja je zadužena sa primkama i medjuskladisnicama da prati stanje zaliha. Ali, zbog integriteta podataka, moraju se i stavke racuna i otpremnice uspjesno insertovati u svoje tabele, pa tek onda da uradim CommitTrans, inace RollbackTrans. Zato i postoje transakcije.

Polje broj racuna je Long (32-bitni integer), ali nije Autonumber.


Uglavnom radi ok, ali u vrlo rijetkim situacijama desi se dogadjaj koji je posljedica kada dve kase istovremeno pokusaju insertovati racun sa istim brojem. A ja bih htio da se to nikad ne desava, tj. da ja to prepoznam i onda nekako ponovim operaciju da uspije svaki put, bez da kasirka zna da je bilo problema.

Pa, sve mi je postalo jasno kad si rekao:



Tada sam shvatio da je ovo forum iskljucivo za Microsoftovu aplikaciju Access, a ja sam mislio da se tu podrazumijeva i Jet engine.

U svakom slucaju, hvala na trudu, a ja cu pokusati na VB forumu.

Ne ljuti se, to ne pomaze resavanju problema.

Shvatio sam da tvoja aplikacija ima jednu tabelu u kojoj cuvas podatke o racunima

Ako temp tabela ima istu strukturu (a trebalo bi) onda se Brojracuna ponavlja u svim rekordima temp. I tebi treba da svaka kasa kad pocne da puni temp tabelu izabere nesto da bude BrojRacuna. Problem nastaje kad dve kase rade u istom momentu. Funkcije tipa 1+MAx(Brojracuna) nisu tliko spore ako je tabela uredno indeksirana i baza lepo dizajnirana. Medjutim, sasvim je lako moguce da dve kase posalju upit u priblizno isto vreme i da se dobije isti rezultat. Posto svaki tvoj racun ima vise stavki, pretrazujes mnogo vise rekorda nego sto bi morao.

Evo kako bi to trebalo postvaiti:

Racuni i prodata roba se uglavnom cuvaju u dve tabele.

Jedna tabela je obicno tblRacun i tu se cuva jedinstveni broj racuna, kao PK i recimo Datum i sta jos treba, zavisi od aplikacije. U tvom slucaju verovatno samo BrojRacuna, Datum i ja bih stavio KasID, da se zna koja je kasa koji racun napravila (mozda i ObjektID?).

Druga tabela se obicno zove tblRacunDetalji ili tblProdataRoba ili slicno i ima polja (BrojRacuna, RedniBrojStavke, ArtiklID, Kolicina, Cena). PK je obicno kombinacija (BrojRacuna, RedniBrojStavke). RedniBrojStavke ide od 1 do N za svaki racun. Polje BrojRacuna je FK na tabelu tblRacun.

Kad ti treba novi racun, radi ovako:

- Napravi tblRacuni i tblRacunDetalji
- Temp tabela treba da ima strukturu kao tblRacunDetalji
Sta se desava u produkciji:
- Korisnik Popuni temp tabelu, kao i do sada, samo BEZ broja racuna.
kad je sve spremno, kasir otkuca ENTER neka se desi ovo:
Begin Transaction
- izracunaj novi broj racuna, kao NoviBrojRacuna = 1+MAx(Brojracuna)
- Insert novi rekord u tblRacun
- dodeli NoviBrojRacuna svim rekordima u temp tabeli
- Append from temp tabela to tblRacunDetalji
- radi sta si zamislio sa otpremnicama, izdatnicama itd
Commit

Posledice:
- Funkcija 1+MAx(Brojracuna) bice brza jer je BrojRacuna PK i nema toliko rekorda kao tvoja trenutna tabela.
- tesko ce se desiti da dve kase izracunaju isti NoviBrojRacuna , jer transakcija traje samo trenutak
- cak i ako se desi da dve kase izracnaju identican NoviBrojRacuna , referential integrity (PK) na tabeli tblRacun ce spreciti unos i cela transakcija ce da padne. Ovo se moze uhvatiti error handlerom i jednostavno ponoviti proracun NoviBrojRacuna
Ovo stoga sto ti BrojRacuna i ne treba sve do momenta upisivanja u bazu niti te interesuje koliki je.

Eto, ispade da je problem u dizajnu baze - jedna tabela za racune umesto dve. Eto, ako se problem resi na potpuno drugi (ne bas potpuno eh?) nacin, onda se tvoj problem i ne moze javiti - znaci - problema nema. Korektan dizajn baze obicno znaci mnogo manje programiranja i mnogo manje nepotrebnih glavobolja.

U zdravlje i srecan rad.

:-)

ja koristim dodeljivanje broja racuna na taj nacin sto drzim sledeci broj u posebnoj tabeli u posebnoj npr racunauto.mdb.
na formi na dogadjaj beforeinsert pozivam, funkciju da poveca autobroj racuna za jedan, tako da se ta tabela jako malo zadrzava.