Sta se desava kada se registrator vrati? Da li opet zauzima svoj stari polozaj, a onaj koji je bio na njegovom mjestu opet u rezervu. Kako se bira registrator iz rezerve koji ce zamjeniti izdati registrator? Ili uzmete bilo koji,samo da polica nije prazna? Po cemu odredjujete prioritet koji ce biti na polici a koji u rezervi? Imaju li registratori u rezervi neki redosled(Polozaj)? Moze li bilo koji korisnik da preuzme bilo koji registrator. Kako Vas korisnik izvjestava sta je u registratoru izmjenio? Kako kontrolisete izmjene. Kako znate sta je prethodno bilo u registratoru, da li se negdje biljezi sadrzaj registratora.... Na sva ova pitanja i jos vjerovatno mnoga treba odgovoriti prije modeliranja baze!

Komplikacija je sa prostorom, nema mesta na policama, nema ni nekog reda kako se popunjavaju (uzima se bilo koji da polica ne bude prazna). Nema ni prioriteta koji je na polici a koji u rezervi, ja znam gde ostavljam one koji se više koriste a za koje nema mesta na polici pa njih "guram preko reda" da mi budu bliži. U rezervi nemaju raspored. Bilo koji korisnik može da uzme bilo koji registrator. Izmene se sa moje strane gledano sastoje samo u broju strana.

Ja sam u onom prikačenom fajlu to previše iskomplikovao (deluje mi da sam terbao da se pomučim još koji dan pre nego pitam za pomoć). U principu je puno jednostavnije samo se prati gde su registratori. Nisu mi ni izmene toliko bitne. Sad se zasmejem kad pogledam šta sam sinoć zakuvao sa tabebelama i relacijama, ona baza koju sam okačio ne radi ništa kako sam ja hteo.

Šta ako se doda još neka polica (sa više od 4 mesta za registratore)?
Kako se postavlja upit da li je registrator sa ID=x na polici?
Kako se postavlja pitanje gde je registrator ID=y?

Osnovna greška je da mesto registratora treba da bude deo sloga koji opisuje registrator ili da bude u vezi sa registratorom. U tom slučaju, jednostavno je odgovoriti gde se registrator trenutno nalazi, a ne da se razdvaja na više tabela.

Tabela polica je potpuno nepotrebna. Ovakve greške u modelovanju često vidim kod onih koji imaju nedovoljno iskustvo u modelovanju, a vuku neke loše navike iz OOP koncepata. Ovde je objekat polica potpuno nepotreban. Onaj ko ima iskustva sa OOP ne bi napravio objekat, a da prvo ne postavi pitanje: Šta objekat treba da radi (princip OOP: Objekti moraju biti aktivni).

Neka cudna arhiva!? Koliko ja shvatam poslovanje arhive, radnik u arhivi bi trebao u svakom trenutku da zna sadrzaj arhive, tj. u kojem registratoru se nalazi koji dokument. Trebalo bi da je njegova ,cak krivicna,odgovornost za dokumente koji se u tim registratorima nalaze.
Znaci ja kao korisnik uzmem od Vas registrator sa 20 strana vaznih dokumenata, izdvojim 5 strana i zapalim ih, a na njihovo mjesto stavim neke druge(nevazne) i to 7 strana i vratim arhivi. Vi evidentirate da sam ih ja uzimao i da sada ima u registratoru 22 strane. Posle mene taj registrator uzme Laza, pa Mika , pa Zika i tako prodje pola godine. Onda Vama dodje kontrola i ustanovi da vaznih dokumenata nema. I Vi idete u zatvor.... The End! :-)

Pitanje je odlicno, znaci da psotavljac teme zna svoj posao i zna tacno sta mu treba, ali nedostaje znanje iz oblasti modeliranja podataka. To je OK, niko se naucen nije rodio. Ispostavlja se da je odgovor na ovo pitanje mnogo tezi nego sto se obicno misli. Ovde se radi o pokusaju pracenju promena statusa nekog objekta (registratora, u konkretnom slucaju).

Ocigledno je da registrator prolazi kroz statuse (oštećeno, rezerva, police ili izdatiregistratori). Moze se desiti da se pojave i novi statusi, na primer 'unisten' ili 'otpisan'.

Prvi pokusaj resavanja ovog problema je obicno naivan (ali ga cine i profesionalci, redovno) i svodi se na resenje koje je Salvatore zamislio - po jedna tabela za svaki status koga smmo se setili na pocetku. Vecina profesionalaca bi uradilia isto to, i vecina profesionalaca ne bi primetila da u takvoj shemi nema nacina da sprecite da isti objekat bude u isto vreme na vise mesta. Salvatore je to odlicno primetio problem sa ponudjenim resenjem i to mora da se postuje. Zbog toga shema ne valja i nema potrebe da to ponavljamo. Shemu je nemoguce popraviti, mora da se baci i napravi nova, tako da mogu da se prate statusi. Slicnu temu imali smo pre godinu-dve, pracenje osnovnih sredstava - ko duzi koji kamion, i kasnije ensto o elektricnim brojilima i plombama. U prvoj temi, o snovna sredstva, dao sam veoma komplikovano objasnjenje kako se radi pracenje prmena stanja. Za brojila je ponudjeno jednostavnije resenje, ali se ne secam da li je bilo prihvaceno ili je nesto drugo uradjeno. Ne savetujem da se ide nazad na te teme i da se pokusa razumeti sta se to tamo desava, isuvise je zakomplikovano. U medjuvremenu sam se bavio tim problemom i naucio da se mnogo jednostavnije (ali jos uvek slozeno) moze resiti problem. U pocetku sam postavljao veliki broj constraints (ogranicenja, validation rules) da bih vremenom shvatio da nisu sva ogranicenja potrebna.

To manje slozeno resenje, sa mnjim brojem ogranicenja hteo bih da predstavim ovom prilikom. Ako smo zainteresovani, mozemo da pocnemo?

Ažurirao sam naslov teme.

Pratimo! :-)

OK, da pocnemo onda. Prvo cemo navesti pravila:

Prati se promena stanja registratora. Sta je promena stanja? Pa, moze se reci da je u nekom trenutku t₁ objekat us tanju S₁ i da u trenutku t₂ objekat prelazi u stanje t₂. To je promena - u nekom trenutko objekat posmatranja prelazi iz jednog stanja u neko drugo stanje. U slucaju nasih registratora, to bi se moglo opisati ovako nekako:

Registrator BrojRegistratora = '12-007/36' u trenutku '12 Januar 2014 11:45AM' je presao iz prethodnog stanja 'na polici' u stanje 'izdato'.
Registrator BrojRegistratora = '12-007/36' u trenutku '16 Januar 2014 13:45AM' je presao iz stanja 'izdato' u stanje 'na polici'.
Registrator BrojRegistratora = '12-007/36' u trenutku '26 Januar 2014 13:45AM' je presao iz stanja 'na polici' u stanje 'arhivirano'.
Registrator BrojRegistratora = '12-007/36' u trenutku '02 Februar2014 13:45AM' je presao iz stanja 'arhivirano' u stanje 'na polici'.
Registrator BrojRegistratora = '12-007/36' u trenutku '03 Februar2014 11:45AM' je presao iz stanja 'na polici' u stanje 'izdato'.

Recenice koje smo navelu su logicki iskazi, tacni - izjave o promenama stanja registratora kroz vreme. Iskazi se mogu generalizovati u logicki predikat, tako sto se umesto konkretnih vrednosti navedu parametri:


Ova recenica se zove predikat relacije koja ce da prati promene stanja registratora. Relacije se predstavljaju tabelama cije zaglavlje je odredjeno predikatom relacije, a telo cine tacni iskazi izvedeni iz predikata. U nasem slucaju bilo bi to ovako:




Dobro pogledajte ovu tabelu. Jedna tabela, a pokriva sva stanja, i cuva trenutke promene stanja. I vsaki objekat je u nekom trenutku u tacno jednom stanju. Tabela je ista, bez obzira o kakvom se objektu radi - registrator, knjiga, rent-a-car auto, zaduzena oprema i slicno. Ovo je samo kako bi tabela mogla da izgleda. DA bi kompletirali dizajn, moramo da postavimo i neka ogranicenja. Na primer, sta bi bio Primary key? Koji su candidate keys? Odakle dolaze vrednosti [BrojRegistratora]? Odakle dolaze vrednosti za stanja? Vrednosti za TrenutakPrelaza su rastuce - svako novo stanje ima veci datum TrenutakPrelaza od prethodnog. Razmislite o ovim stvarima. Vidite li jos neka ogranicenja koja bi trebalo postaviti?

Napravit prvu verziju tabele, prema datoj slici. Nemojte da dodajete autonumber. Postavite UNIQUE indexe za svaki candidate key koji mozete da smislite. Unseite nesto podataka, za nekoliko registratora. Za vezbu, napravite kvarije kojo daju odgovor na pitanja:
1) Za zadati objekat i zadati datum, prikazati stanje objekta na taj datum
2) Prkazati polednje (tekuce, trenutno stanje) svih objekata
3) Koji su objekti u stanju 'na polici' u ovom trenutku?
4) koji su objekti u stanju 'izdat' u ovom trenutku?
5) Koji su objekti bili u stanju 'izdato' na pocetku meseca?
6) koliko puta je zadati objekat bio u stanju 'izdato'
7) koliko vremena prodje od momenta izdavanja objekta do vracanja?

Sutra cemo da nastavimo. Ovo je samo kostur tabele, dodacmo jos kolona, da bismo obezbedili postovanje ogranicenja. Dodacemi i neke korisne kolone - ako je objekat izadt, kome je izdat? Ako je objekat na polici, na kojoj je polici (ukoliko moze biti na raznim policama)? Za sve ovo trebaju nam dodatne kolone i dodatna ogranicenja. Polako, igrajte se malo postavljenom tabelom i pokusajte da napravite kverije. Sutra cemo da nastavimo, ili z akoji dan ako sutra nismo spremni. Ovo sto smo ispricali zahteva vise od jednog popodneva da se dobro razume, a kveriji zahtevaju jos vise vremena...

:-)

Validaciju ne umijem baš napisati ali evo šta ja primjećujem:
PrimaryKey definitivno mora biti [BrojRegistratora]+[TrenutakPrelaza]
[TrenutakPrelaza]<=Now() - TrenutakPrelaza ne moze biti veći od trenutnog datuma i vremena
[TrenutakPrelaza]>Last[TrenutakPrelaza] - TrenutakPrelaza mora biti veći od zadnjeg TrenutkaPrelaza
[PrethodnoStanje]=Last[NovoStanje] Or Last[NovoStanje] IsNull - PrethodnoStanje mora biti jednako NovoStanje iz prethodnog unosa ako ono postoji
[NovoStanje]<>[PrethodnoStanje] NovoStanje mora biti različito od PrethodnogStanja

Ovi izrazi koje sam napisao vjerovatno nisu ispravni... :-)

Zahvaljujem na aktivnosti


Navedeni izrazi su napisani najbolje sto se moze. Ne trazi se da se napise sintaksno ispravni izraz, trazi se logika, a logika je uglavnom tacna. Da ih malo komentarisemo:

Uslov 1) - tacno, kombinacija ( [BrojRegistratora], [TrenutakPrelaza]) treba da jedinstveno odredjuje red

Uslov 2) i ne mora da se postavi, jer mozemo odluciti da u nekoj buducnosti napravimo prelaz iz stanja u stanje ( Password iz stanja 'aktivan' prelazi u stanje 'istekao' na neki dan u buducnosti).

Uslov 3) Proizilazi iz uslova 1

Uslov 4) proizilazi iz uslova 1, a NULL bi vazilo za pocetno stanje (Iza stanja NEPOZNATO presli smo u neko pocetno stanle) Nepoznato = NULL, to je to

Uslov 5) zavisi od toga kako definisemo dozvoljena stanja. Ako je trenutno stanje "Radovi u toku" zasto ne bi bilo i buduce stanje "Radovi u toku", samo sa razlicitim datumom, i moza komentarem?

Mozete da napravite jos dve tabele:

Stanja, sa vrednostinma: {'oštećeno','rezerva', 'na polici', 'izdati registratori'}
i i DozvoljenePromeneSTanja

Prelazi stanja znace:
NULL -> 'na polici' znaci 'Novi registrator je stavljen na policu. Prethodno stanje - nopznat = NULL'
'na polici' -> 'izdati registratori' znaci 'sa police registrator je presao u stanje 'izdati registrator''
'izdati registratori' -> 'oštećeno' 'znaci registrator koji smo izdali vracen je ostecen i nije na polici (dobro bi doslo i stanje 'izgubljen' i/ili 'unisten''
'izdati registratori' -> 'na polici' znaci 'ono sto smo izdali varceno je na policu'

Ovde je problem sto PK nece da prihvati NULL vredost za pocetno stanje..... E tu pocinje resavanje problema. Za sada, napravite tabele STanja i DozvoljenePromeneStanja. TAbele popunite kako mislite da treba - stanja koja mislite da ce trebati i koji su prelazi dozvoljeni. Dozvoljeni prelazi su dobar kandidat za kontrolu kolona 'PrethodnoStanje','NovoStanje' u tabeli koju smo definisali ugrubo na pocetku....

Dosta je za danas, sutra cemo dalje.

Evo ja sam malo majstorisao, mada ne znam da li je to dobro... nemam više vremena za večeras a sjutra sam zauzet. Pratiću vas sa telefona...

Odlicno, hvala Nenadu jos jednom. ne mogu da te stignem

Format baze je MDB, odlicno, i svi ostali primeri bice MDB.

Tabele su dobro postavljene, kao i relacije. Dobri test podaci. Ne dirati nista vise do daljnjeg.

Kveriji su OK, mada mi se ne svidaj upotreba operatora LAST. Deluje da radi, iako ne znamo sta u stvari znaci LAST - poslednji uneti podatak? poslednji u redosledu PK? U ovom slucaju verovatno nema veze, jer je redosled po PK isti kao i redosled unosenja, ali generalno LAST ne treba previse upotrebljavati. Ovo sto vazi u Accesu vazi i za ostale RDBMS - MS SQL, ORACLE, a tamo nema lSAT/FIRST, ima samo MAX i MIN.

Sutra cemo da nastavimo.

Kao prvo, Zidar svaka čast!



Moram ovdje primijetiti da uslov 3) baš i ne proizlazi iz uslova 1) (ili sam ja krivo shvatio šta si mislio reći =) )
Jer, uzmimo ovaj primjer:



Nekome padne na pamet ubaciti unutra podatak [1, 17.01.2013 11:14]
Dakle, primarni ključ jest dobro definiran ali ipak mislim da bi trebalo postaviti validaciju da novo Vrijeme_izmjene ne može biti manje od MAX[Vrijeme_izmjene]

Auuu, ne mogu da verujem... Hvala svim učesnicima u diskusiji a posebno Zidaru!

Query-je bi trebalo imenovati:
1 PromenePoRegistratoru
2 PoslednjaStanjaZaSve
3 TrenutnoNaPolici
4 TrenutnoIzdati
Funkcija LAST u kombinaciji sa GroupBy nad BrojRegistratora radi odlično. Ona koristi redosled unetih zapisa. MIN/MAX može nad kolonom TrenutakPrelaza.

U redu je ova logika sa sa dozvoljenim promenama stanja, ali bi trebalo (bar na pocetku) dozvoliti prelaz iz null u bilo koje stanje, jer cemo u pocetku, kad baza zazivi imati registratore koji se trenutno nalaze u raznim stanjima (izdat, na polici...) po unosenju stanja svih registratora mogu se vratiti ogranicenja koja je Zidar dao.

Hvala svima na interesovanju i zapazanjima Nismo gotovi sa postavljanjem ogranicenja, niti smo poakzali kako ce sve da radi. tabela koju smo dali jeste ono sto bi korisnik verovatno hteo i trebao da vidi. Bice jos kolona, koje sluze da se garantuju uslovi ogranicenja, a koje korisnik ne mora da zna uopste.

OK, nisam bio dovoljno precizan. Zanemarite za trenutak ovu tvrdnju, nije ni bitno sta odakle proizilazi. Ovo sto sledi je bitnije:

Odlicno zapazanje, pokazacemo kako se sprecava da se naknadno ubaci nova promena izmedju dve postojece.

Jos jedno ispravno zapazanje, zahtev ako hocete: Naravno da cemo moci uneti pocetna stanja, i bez NULL vrednosti, a postojeca ogranicenja za prelaz is ztanja u stanje mozemo modifikovati bez promene strukture tabela i promene conatraints.

Dajte mi samo malo vremena, tek sam dosao na posao...

U svoj gužvi, trudeći de da shvatim sve napisano i ostanem u toku zaboravio sam da odgovorim na nenadmarkoni-jeva pitanja.

Pretpostavljam da postoje razne arhive, ova moja služi da skladišti registratore u kojima su tabele sa podacima merenja.

Ono što sam ja hteo da pratim je:

- Gde je registrator (može biti: na polici, zadužen , u rezervi ili oštećen). Ako je na polici zanima me broj police i broj mesta na polici. Mesta na polici nisu rezervisana i nikad nisu prazna. Kada jedan registrator ode sa police (na zaduženje, ili se ošteti) na njegovo mesto stavljam neki iz rezerve (bilo koji). Rezerva je ustvari rezervno mesto (pod druge prostorije) gde se nalazi samo nekoliko registratora za koje nema mesta na policama. Pošto su registratori malo kvalitetniji, kada se desi da se neki ošteti ne bacam ih već ih odlažem (takođe pod druge prostorije) za slučaj da može da se uklopi sa nekim drugim oštećenim (negde se ošteti mehanizam negde kutija negde se iskidaju "gaće" za kartice).
- Koliko kartica registrator ima u sebi (broj kartica se može menjati kod svake promene lokacije)

Hteo sam da vodim i evidenciju, kad je registrator menjao lokaciju, gde je bio, zašto, i koliko je stranica imao u tom trenutku.

Sve mi je to delovalo jednostavno, pa sam se latio Access-a. Krenuo sam sa dve tabele. Zatim sam obrisao obe pa napravio tri nove i tako je moja baza rasla do trenutka kada sam postavio pitanje.

Mislim da je bitno definirati šta podrazumijevaš pod tim gdje je bio i zašto. Jesu to opisna polja ili su to možda osobe, uredi, sektori?

To su sve ispravni zahtevi i neke od njih cemo pomenuti. Svrha teksta je da oni koji dosta znaju o Accesu probaju jedan novi metod. Za pocetnike je nivo previsok, ali ne smeta da se posmatra.

Da se vratimo poslu.

1. Dodajmo tabelu Registratori {BrojRegistratora, Sadrzaj} PK (BrojRegistratora), povezati sa tabelom PracenjePromenaStanja, ovako:


2. U tabelu PracenjePromenaStanja dodajmo kolonu StariTrenutakPrelaza, datetime. To je trenutak kada je u registrator usao u prethodno stanje. Sada ce predikat za novu tabelu izgledati ovako:

Registrator [BrojRegistratora] presao je u novo stanje [NovoStanje] u trenutku [TrenutakPrelaza]
iz starog stanja [PrethodnoStanje] u koje je presao u trenutku [StariTrenutakPrelaza].

Komplikovano, zar ne? Jeste, ali takav je zivot

Popunjena tabela izgleda ovako, sortirano po (BrojRegistra, TrenutakPrelaza):


Primetite da se podaci ponavljaju. Za sve redove osim prvog vidi se da
1) PrethodnoStanje postoji u prethodnom redu u koloni NovoStanje
2) STariTrenutakPrelaza postoji u prethodnom redu koloni TrenutakPrelaza

Ovo znaci da bismo mogli da postavimo FOREIGN KEY (BrojRegistra, StariTrenutakPrelaza, StaroStanje)
REFERENCES PracenjePromenaStanja (BrojRegistra, TrenutakPrelaza, NovoStanje). Ovo znaci veza tabele sama na sebe, gde je roditelj prethodni red a dete je posmatrani red, ovako nekako:

Problem je sto ovo ne mozemo da uradimo iz dva razloga:
1) jer pocetni red nema roditelja.
2) treba nam UNIQUE PracenjePromenaStanja (BrojRegistra, TrenutakPrelaza, NovoStanje)
Resenja:
1) pocetni red ce imati ropditelja ako vrednosti za prethodno stanje i novo stanje i trenuci prelaza budu identicni. Za tako nesto nam treba novi dozvoljeni prelaz, Iz stanja 'Na polici' u stanje 'Na polici'. Pocetni rekord imace dakle NovoStanje=StaroStanje='Na polici'. Ako unesemo neki dovoljno daleki datum u proslosti, imacemo teorijski pocetni rekord za sve registratore. Odatle je lako dodati stvarni pocetni rekord, drugi fizicki, - neki registratori su izdati, neki su na polici, neki su odavno arhivirani....

2) Napravimo UNIQUE index (BrojRegistra, TrenutakPrelaza, NovoStanje). I dalje je (BrojRegistra, TrenutakPrelaza) PK. Novi index formalno ima jednu kolonu vise, ali nam je to potrebno da bismo poatavili FK. UNIQUE constraint sa suvisnim kolonama zove se inace Super Key. Ako ste se pitali cemu sluzi Super Key osim u teoriji - sad vidite cemu moze da sluzi.

3) Sad mozemo da postavimo FK. FK nam garantuje da za svaki tekuci red mora da postoji neki prethodni red takav da PrethodniRed (BrojRegistra, TrenutakPrelaza, NovoStanje) je isto sto i TekuciRed (BrojRegistra, StariTrenutakPrelaza, StaroStanje). I dodajmo ogranicenje [StariTrenutakPrelaza] < [TrenutakPrelaza], da garantujemo rastuci redosled datuma.

Sad smo tacno na pola puta i obezbedili smo sledece:
1) Svaki rekord ima roditelja.
2) Prvi rekord je sam sebi roditelj - ne mozete uneti prvi rekord ako nije NovoStanje=StaroStanje='Na polici', TrentakPrelaza = StariTrenutakPrelaza
3) TrenutkPrelaza je veci u svakom rekordu nego sto je bio za roditelja.

Jos ne mozemo da garantujemo da nece moci neko da ubaci novi rekord negde u sredinu. Tacno, ne mozemo da garantujemo, ali je veoma tesko to uraditi. Pokusajte rucno da unesete neki rekord izmedju postojeci. Niti mozemo d agarantujemo da ce svaki rekord imati tacno jednog roditelja. Ali je veoma tesko prekrsiti ovo pravilo, rucno. Pokusajte, lakse je nego ubacivanje rekorda iamdju postojecih, ali ipak tesko. Uopste, rucno popunjavanje tabele PracenjePromenaStanja nije tako jednostavno. To u poprilicno stiti tabelu od namernog ili nenamernog unosa nelogicnih i nekompletnih podataka. Ovo znaci da ako napisemo kod koji nam pomaze da unesemo nove rekorde, manje-vise svi ce morati da koriste taj kod, rucni unos je prakticno veoma otezan.

Ovo se nalazi u zakacenom Access fajlu:


Naravno da se necemo zadovoljiti konstatacijom da je rucni unos pogresnih podataka 'prakticno' nemoguc. Za sada, probajte da napisete kodf koji ce da prebaci podatke iz prethodnog rekorda u novi, kada korisnik unese BrojRegistratora i NovoStanje. Kod treba da bude na BeforeUpdate za formu frmPracenjePromenaStanja, koja je datasheet. Kod treba da radi samo za rekorde koji nisu pocetni, smatra se da vec postoji pocetni rekord (NovoStanje=StaroStanje='Na polici', TrentakPrelaza = StariTrenutakPrelaza).

Pocetni rekord u tabeli PracenjePromenaSTanja treba da se doda kada se u tabelu Registratori doda novi regitrator. Podaci za pocetni rekord:
TrentakPrelaza = StariTrenutakPrelaza = Registratori.DatumKreiranja. Pokusajte da napisete nezavisnu funkciju koja:
1. proverava da li postoji rekord za zadati BrojRegistra u tabeli PracenjePromenaStanja
2. ako postoji rekord, funkcija ne radi nista
3. ako ne postoji rekord, funkcija INSERTuje novi rekord (pocetni rekord) za dati BrojRegistra u tabelu PracenejPromenaStanja

Funkcija se poziva sa Form After_Update eventa za formu frmRegistratori (obicna forma, sluzi za unos i editovanje podataka o registratoru)

AKo ne uspete da nparavite trazeni kod, nema veze. Imacemo jso izmena na tabeli PracenjePromenaStanja i trebace nam potpuno novi kod. Ovo je samo za vezbu.

Imate cime da se zabavljate do sutra. Ja necu imati vremena da odgovaram na poruke danas, ali se nadam da cu moci bar da ih pogledam, ako bude novih poruka.

Uzivajte


<sub>[Ovu poruku je menjao Zidar dana 05.02.2014. u 18:02 GMT+1]

[Ovu poruku je menjao Zidar dana 05.02.2014. u 18:03 GMT+1]


[Ovu poruku je menjao Zidar dana 05.02.2014. u 18:05 GMT+1]

[Ovu poruku je menjao Zidar dana 05.02.2014. u 18:07 GMT+1]


[Ovu poruku je menjao Zidar dana 05.02.2014. u 18:09 GMT+1]</sub>

Napravio sam par formi u stilu @Zidar i ubacio sam DatePicker sa kojim je moguce ubaciti i odabrano vrijeme (izvor UterAccess) na frmRegistratori-DatumKreiranja-dupli klik. Ovo treba omoguciti za unos novog registratora a onemoguciti kada se forma otvori za prikaz- da nebi doslo do nenamjerne izmjene. Citav dan sam vozio i jako me boli glava pa za sad toliko, ne mogu dalje danas ... :-(

@salvatore Svima se u pocetku cini da je jednostavno, i meni se cinilo. Istina je sasvim suprotna, posao developera je sve samo ne jednostavan i znanje koje oni na ovom forumu prenose time je vrednije- pored svog posla odvojiti vremena da nama pocetnicima pomazu i objasnjavaju. Ipak svi smo tu radi korisne zabave pa nemojte moje pojedine poruke shvatati previse ozbiljno- naravno da ne sumnjam da poznajete svoj posao i da tacno znate sta Vam treba. Problem je kako rece @Zoran.Eremija da "...dok je pripovedacu sve jasno slusaocu bas i nije. " , i zbog toga dok se dodje do ispravnog modela baze treba odgovoriti na mnoga pitanja i potpitanja. :-)

Zidar smijem pitati čemu dvije tabele [Stanja] i [Stanja_1]? Ili Access ne podržava da dva polja imaju FK na isto polje druge tabele? Ili je neki poseban razlog?

Koliko sam ja upucen Access u ovom slucaju (isto kao i kod rekurzivne veze) formira drugi pogled na tabelu-entitet iako fizicki postoji samo jedna tabela. Otuda u relacijama prikaz drugog pogleda na tabelu Stanje(Stanje_1)

Bogami si prilicno zakomplikovao zivot sa ovim vezama ;)
Uspeo sam da uradim formu za unos promena, kao i formu za unos registara.
Kod popisa registara prilikom unosa moraju da se odrade dva insetra u tabelu promene, prvi kao inicijalni, jer je jedini dozvoljen unos na polici-na polici i drugi gde belezimo trenutno stanje registratora

Recimo neki registrator promeni mesto. Treba da znam gde je (ime i prezime osobe kod koje je ili broj police ili rezerva), kad je tu dospeo (datum), odakle (rezerva ili sa nekog od mesta na policama ili se vratio sa zaduženja), koliko je kartica imao u trenutku promene mesta (trocifren broj), i zašto je menjao mesto (tekst).

Istina. Koliko god da je ovo napredniji prolem, ja kao totalni početnik prateći ovu diskusiju "iz prve klupe" za dva dana naučio sam puno više nego u proteklih dvadesetak dana čitanja i kopanja po internetu.

Želim još jednom da se zahvalim svim učesnicima u diskusiji a posebno Zidaru koji je nesebično podelio znanje i kompletnom ES forumu. Ne postoji mesto na internetu gde sam mogao naći više korisnih informacija i veću bazu znanja na jednom mestu i još na svom jeziku.

Ja dobijam Run-time error 3075 kod unosa registratora. DoCmd.RunSQL str zaustavlja script ali odradi unos.

Bas mi ne date da radim posao za koji me placaju Juce sam 4-5 sati proveo na ovom projektu. Danas necu imati toliko vremena, iamm nesto da zavrsim tako da proradi u ponedeljak, a ne radi mi s epreko vikenda.

Pitanja koja su postavljena su odlicna. Evo odgovora:
Q1: Odlicno pitanje. Odlicno je i Nenad pokusao da objasni - tacno, ali ne i kompletno. Rekli smo da je svaki red dete nekog prethodnog reda. To imas kad radis hijerarhije - ko je kome nadredjen u firmi. To je ono sto je Nenad hteo da kaze. Kod hijerarhije, jedan roditelj red moze imati vise dece redova. U ovom slucaju zelimo d apostignemo da je svaki red dete tacno jednog roditelj reda. Znaci, u hijerrahiji roditelj:deca = 10,1 ili vise), a mi zelimo da imamo 10,1), da svaki roditelj ima ne vise od jednog deteta. Jos uvek nismo postigli 1:1, za sada imamo 1:vise, ali i to je nesto.

Mozda ce biti jasnije ako napisem SQL izraz za FOREIGN KEY:

Obrati paznju na veze - one crtice izmedju naziva kolona. StariTrenutakPrelaza u dete redu gleda u TrenutakPrelaza u roditelj redu. Ono sto je bilo trnutno stanje i trenutak prelaza za roditelja postaje stro stanje i stari trenutak u dete redu. Nadam se da je sada jasnije. Ponavlajm, ovo je samo 50% posla. Moramo jos da garantujemo da svaki roditelj ima ne vise od jednog deteta.


Q2: Tacno. U slucaju kad je pocetno stanje 'na polici' onda je dovoljan samo jedan unos. Nisam proveravao kod, ali verujem da radi. Ja cu na kraju dati moj kod, jer iz iskustva znam d aprvi pokusaji daju bespotrebno mnogo linja koda pa je tesko shvatiti o cemu se radi.

Q3: ispravan zahtev. deo odgovora vec imas:
1) kad je tu dospeo (datum) = TrenutakPrelaza = trenutak prelaza u Novo Stanje
2) Treba da znam gde je = NovOStanje
3) odakle dolazi = STaroStanje
4) koliko je kartica imao u trenutku promene mesta = broj prethodnih rekorda za posmatrani registrator = broj prethodnih promena stanja
5) ime i prezime osobe kod koje je ili broj police ili rezerva = to cemo dodati na kraju. DA bi ovo postigli, trebaju nam dve tabele, jedna gde su popisane osobe koje mogu uzeti registrator; i druga, gde su popisane sve moguce police i fizicka mesta gde se moze nalaziti registrator kad nije kod neke osobe (nije u stanju 'izdato nekome')

NAzad na posao:

1) Sad, pronadjite temu u kojoj sam dao program za pracenje sastanaka. U tabeli satsanci postoje dve kolone, Rb i StariRb. Obe su tipa integer, requoired, >0. Pokusajte da otkrijete kako je tamo garantovano da se Rb povecava za 1 u svakom redu.

2) Dodajte takve dve kolone u tabelu PracenjePromenaStanja. Popunite rucno tako da su za inicijalni red Rb = StariRb a za sve ostaleredove unesite Rb = StariRB +1. Na nivou tabele dodaje validation rule
. Tamo vec treba da postoji izraz pa ce novo table validation rule izgledati ovako: pazite an zagrade!

3) Uvedite novo UNIQUE ogranicenje (index) po kolnama (BrojRegistra,Rb)

3) Dodajte jos jednu relaciju tabele na samu sebe, evo SQL izraz, vi ga napravite u grafickom wizardu

Sad imamo garanciju da ce se Rb povecavati za 1 u svakom novom redu. Ovaj usloznaci da necemo moci naknadno da ubacujemo redove izmedju postojecih redova. Ovo znaci da je od sada pa nadalje dopusteno jedino dodavanje redova na kraj tabele. Ovim smo zavrsili 75% posla. Ostaje jos da garntujemo da jedan roditelj nema vise od jednog deteta.

Cak i ako ne idemo dalje, posle dodavanja Rb kolona jos je teze dodati redove koji krse pravilo 'ne vise od jednog deteta po roditelju'. Posle dodavanja Rb kolona, pokusajte rucno dodate drugo dete nekom od roditelj redova, tek da dobijete ideju koliko je to tesko. vec smo postigli da je prakticno nemoguce brljati po sistemu, ali je torijski moguce. To cemo u sledecm koraku, sutra, a koristicemo kolone Rb i StariRb. Neka to ceka sutra, imacete dovoljno muke i sa ovim Rb kolonama.

Izgleda da sam antitalenat za kodiranje!?! :-( Pokušao sam da napravim kodove koje je @Zirar postavio za zadatak i nisam uspio.Pokušao sam i sa Query-em. Zadnji pokušaj je ovde prikazani kod na BeforeUpdate - da provjeri da li postoji rekord, pa ako ga nema da najprije snimi zapis u tabelu Registratori pa da doda početni rekord u tabelu PracenjePromenaStanja ali kad pokusam da zapamtim zapis dobijam Error 2115 - da kršim ValidationRule ali ne znam koje. Dodao sam Rb i StariRb i iskljucio sam DatePicker na formi Registratori kad se otvara već postojeći rekord, a nisam isto to uspio da iskljucim u subformi za već unijete zapise. Za sve datume na tabelama sam promjenio u General Date, i malo sam izmjenio formu DatePicker u dijelu za vrijeme.
U subformi za Rb sam unio DefaultValue da podize za 1 i onemogućio pristup Rb,StariRb,StariTrenutakPrelaza i PrethodnoStanje.
Uspio sam da onemogucim DatePicker i izmjenu NovoStanje za vec unijete rekorde, a omogucim za nove rekorde.


_{[Ovu poruku je menjao nenadmarkoni dana 06.02.2014. u 22:15 GMT+1]}
...I napravio gore- sad otvara i upisuje vrijeme i u druga polja , ha,ha,ha...

_{[Ovu poruku je menjao nenadmarkoni dana 06.02.2014. u 22:33 GMT+1]}

http://www.elitesecurity.org/t467189-0#3322038

Unesena nova ogranicenja, kao i dodat kod formama da postuju ogranicenja

Ispravljene neke greske

Hvala nenadu i Dexxxl na trudu. Nenad je pogodio povezivanje roditelj Rb na dete StariRb. Dexxxl je skoro pogodio povezivanje i uneo vise rekorda. Ja sam dovrsio povezivanje u priemru koji je dao Dexxxl. Taj primer cu koristiti u ovom odgovoru jer mi se cini da je slika sa relacijama nesto citljivija.

Primetite da su nenad i dexxxl dodali kolone Rb i StatriRb na razlicitim pozicijama, jedan na pocetku atbele, drugi na dnu. Po relacionoj teoriji ovo nije vazno, i u praksi nije vazno, sve ce lepo da radi u oba slucaja i sve ce formule i izrazi biti potpuno isti. Izabrao sam dexxxlov primer jer je slika nesto citljivija, sto nema nikakvog uticaja na logicku i sintaksnu tacnost ponudjenih resenja. Samo se lakse vidi i to je sve.

Ovako se dakle povezuju Rb i StariRb:

Indeksi koji ovo omogucuju su:

Rekao sam da se jos uvek mogu uneti pogresni podaci (nije mi uspelo od prve, ali je na kraju uspelo):
Pogresna su poslednja dva reda - imaju isti StariTrenutakPrelaza kao jedan od starijih rekorda, a jedan od njih ima i pogresan TrenutakPrelaza - nije veci od prethodnog rekorda.. Ako nije jasno, evo ista slika, sortirano po TrenutakPrelaza:

Dakle, u ovom postu, osim povezivanaj Rb, nista novo, a to su sigurno neki i sami uspeli, kao Nenad.

Sledeci post - dacemo kod za unosenje podataka, tako da korisnik i ne vidi ove pomocne kolone.

Evo i koda za automatsko izracunavanje svih potrebnih pomocnih kolona, koje smo naravno sakrili od korisnika. Korisnik na kraju vidi samo ovo:


Za kod, pogledajte kod iza forme frmPracenjePromeneStanja. Ukinuo sam kod na OnCurrent, i dodao na Before_Update za formu. Da bi pozvali onaj specijalni DatePicker, treba da uradite dblclick na kolonu TrenutakPromene. Ako ne, onda ce TrenutakPromene dobiti vrednost =now() .

Ko se umorio, moze da smatra da je ovo karj price. Tabela PracenjePromeneStanja nije 100% sigurna od unosa losih podataka, ali je veoma mala sansa da ce neko ko ne poznaje ovu problematiku u detalje biti u stanju da unese bilo sta, ispravno ili neispravno, u tabelu.

Posto smo mi profesionalci, u sledecoj poruci, verovatno u ponedeljak, dodacemo dve tri izmene na tabelama i garantovacemo ispravnost podataka. Posao nije veliki ali trazi razumevanje, pa to sotavljamo za posebnu temu.

Posle toga cemo dodati kolone "Ko je uzeo Registrator", za to ce nem trebati tabela Korisnici: {KorisniKID, int, NOT NULL, PRIMARY KEY}

Meni nije jasno kako je ikako moguće unijeti pogrešne podatke ni u ovom stanju kako je sad, i ne znam šta bi se još moglo dodati . Svaka čast!
Da li ovako kako je znači da frmRegistratori ne moze da se iskoristi za unos novog registratora već mora postojati posebna forma? Ja sam uporno to pokušavao .
U prethodnim postovima @salvadore je naveo:
"koliko je kartica imao u trenutku promene mesta (trocifren broj)".
Sta su kartice u registratoru? Nešto kao broj strana koje sadrzi registrator ili sam pogrešno skontao? Pitam zato što ne razumijem ovaj dio koji je @Zidar dao u odgovoru:
"4) koliko je kartica imao u trenutku promene mesta = broj prethodnih rekorda za posmatrani registrator = broj prethodnih promena"

Da da, broj strana, kartice su ustvari papiri a5 formata.

Police su slične kao ove

[att_img]

samo što imaju po 4 a ne po 8 mesta, spratovi suobeleženi redom od 001, a pozicija registratora je obeležena od 1 do 4 brojem. Isto tako ređam i u rezervi (iako tamo trenutno nema polica).

Ipak moze, prenio sam kod od @Dexxxl na formu frmRegistratori. :-)

Izvinjavam se sto se juce nisam javio. Ostao sam kuci zbog prehlade, aod kuce nisam mogao nikako da se ukljucim na elitesecurity.org, dobijao sam stalno connection time-out. nastavicemo danas, ne ovog momenta, jer moram da stignem sta sam juce propustio na poslu. Ne mogu ni ja da zabusavam beskonacno

Kao sto rekoh, konacno resenje je blizu - samo korak nas deli. I jednostavnije je od onoga sto imamo.
1) obrisite one dve relacije PracenjePromenaStanja_1 i PracenjePromenaStanja_2 (desnim klikom kliknete na relationship liniju i izaberite Delete)
2) Promenite indexe, da izgledaju kao na slici ispod. PK ostaje kakakv je bio, UNIQUE_2 ostaje kakav je bio, uklonite UNIQUE_1 i napravite novi umesto njega, SuperKey. SUperKey je matematicka unija atributa atributa koji cine PrimaryKey i Unique_2 i doadli smo NovoStanje
3) Dodajte novu relationship, sa SuperKey na kolone koje su 'stare', kao na slici ispod

To je to. Kod ostaje isti, ne dirajte. Sve ostalo ostaje isto, ne dirajte nista. U tabeli Stanja sam jos prosli put dodao kolonu BrStanja, i stanje 'Na polici' je dobilo broj 0 - to je pocetno stanje koje ce kod da uzme kad bude tebalo da se doda inicijalno stanje. Obrisao sam stare rekorde i uneo nove za nekoliko registratora, ne za sve.

Promenio sam start-up frmu - dodao uputstvo za upis promene stanja. Inicijalno stanje moze se dodati na isti nacinkao i svako drugo stanje, kroz formu. Ostalo nisam dirao. Automatski unos stanja kad se doda registrator, ne formi UnosRegistratora, nisam menjao, ali mi s ecini d ane radi uvek dobro.


Vazne napomene za tabelu PracenjePromenaStanja:
1. pojedinacni rekordi, osim poslednjeg, ne mogu se ni brisati ni menjati
2. moguce je izabrati sve rekorde za jedan registrator i pokusati DELETE - samo ce poslednji biti obrisan
3. moguce je izabrati SVE rekorde u tabeli i sa DELETE svi ce biti obrisani. Zbog ovoga imate puno razloga da sakrijete tabelu od korisnika ili da je zastitite. jedan od nacina zastite je da imate dodatnu tabelu, sa dve kolone, recimo (BrojRegistratora, Rb) koja ce se popunjavati automatski, kad god popunite PracenejPromenaStanja. To ostavljam da sami isprogramirate. Onda napravite relaciju - PracenejPromenaStanja je roditelj, a nova tabela je dete. Postojanje rekorda u dete tabeli sprecava brisanje rekorda u roditelj tabeli.

Sutra dodajemo sta nam treba da pratiomo i KO je uzeo registrator. Nema ogranicenja ko moze uzeti koliko registratora - u Accesu je to ogranicenje veoma tesko postici bez programiranja. Isto je tesko u Accesu postici bez programiranja pracenje na tacno kojoj se polici nalazi registrator kada je u stanju 'na polici', pa to necemo pokazivati. Ko hoce, moze da programira da se na Before Update pri promeni stanja proverava da li je covek vec dostigao dozvoljeni broj uzetih registratora, kao i da se pazi da se na jednoj lokaciji moze nalaziti tacno jedan registrator u jednom momentu.

:-)

Evo, dodali smo i radnike. Sad se zna kod koga je registrator.

Promene:
1) dodali smo novu tabelu, Radnici {SifraRAdnika, int, PK}

2) dodali novu kolonu u PracenejPromenaStanja - (SifraRAdnika, int, NULL), primetite da Required property mora biti NO

3) dodali novi uslov na nivou tabele (table validation rule), kaze [NovoStanje] = 'Izadti Registratori') <=> [SifraRAnika] IS NOT NULL) sto zanci ako je registrator izdat, mora se upisati kome je izdat. Ako je u nekom drugom stanju, onda se ne sme upisati sifra radnika. U Accesu postoji operator za logicku ekvivalenciju i implikaciju, zovu se EQV i IMP. To sma nedavno saznao, u knjizi Access 2.0 (!)

4) Na formu "frmPracenjePromeneStanja", koja je podforma glavnoj formi frmRegistratori_Master, so dodali kolonu SifraRAdnika. Tu kolonu popunjavata kad je NovoStanje = 'IZdati Registrator', a ne smete je popuniti kad je NovoStanje neko drugo stanje.

Inace, vecina RDBM sistema ima samo AND, OR, NOT operatore. Sta onda radimo? Onda se setimo da se
P => Q moze napisati kao (NOT P OR Q). Posto se P<=> Q moze pisati P=>Q AND Q=>P, onda se i to moze napisati preko NOT i OR:

P<=> Q
<=>
(NOT P OR Q) AND (NOT Q OR P)

Tako je napisan onaj uslov u sredini: Rb=1 OR RB = StariRB + 1 sto je isto (ekvivlentno) sa izrazom
(Rb<>1 => Rb=StariRB+1)



Nikakvih promena u prgramiranju nema.

Nisam siguran da li ispravno razmišljam (malo je ovo visok nivo za mene). Može li se dodati i tabela za mesta na policama na isti način? Recimo napravim tabelu police gde bih u ID spojio broj police + broj mesta na polici (recimo polica 8 i njena mesta 1,2,3 i 4 bi bili predstavljeni na primer 0081, 0082, 0083, 0084 ili 008.1, 008.2).

Pitanje br.2:

Ako odredim da je neko polje Combobox, i ako nije dozvoljeno da se pojavljuju duplikati, da li je moguće da se u Combobox-u ne pojavljuju već upotrebljene vrednosti.


_{[Ovu poruku je menjao salvatore. dana 14.02.2014. u 11:27 GMT+1]}

Moze, na isti nacin kao sto smo resili radnike. Ovo vazi samo za stanjej "Na polici". I nema garancije da neces imati na istoj poziciji
1. dodas tabelu Police {[MestoNaPolici] text PRIMARY KEY;..ostale kolone;..}
2. dodas novu kolonu u PracenjePromenaStanja: ADD COLULMN MestoNaPolici text
3. postavis relationship za Police.MestoNaPolicina PracenjePromenaStanja.MestoNaPolici, tabela Police na roditelj strani
4. dodas novi uslov na nivou tabele NovoStanje = 'Na polici' EQV MestoNaPolici IS NOT NULL
5. dodati novu kolonu na formu za unos promena - MestoNaPolici i popunjavati kad se predje u stanje 'Na polici'

Losa strana: mozes u jednom istom momentu da dodelis isto mesto na polici za vise regsitratora, sto nije logicno. Ako hocemo da izbegnemo vise registratora na jednom istom mestu, stvari ce se previse zakomplikovati, i na strani strukture baze i tabela, i na strani programiranja. Dalje, u praksi je isuvise lako praviti greske i upisati pogresnu poziciju. da se ne bi pravile greske, potrebno je izmeniti ceo proces izdavanja i vracanja registratora. To obicno zahteva i fizicke izmene na policama, registratorima, obuku ucesnika u proces, trista cuda. Zato ne preporucujem da se to uradi, barem u pocetku. Pitanje ej u svakom slucaju interesantno, i mozda neko moze da ga resi, sada kad smo naucili nove tehnike upravljanja dinamickim sistemima (dinamicki sistem se bavi cuvanje podataka o promenama, staticki sistem se bavi cuvanjem podataka o objektima)

Možda u ovom slučaju nije baš bila dobra ideja da se za inicijalnu vrijednost u PracenjePromeneStanja prilikom dodavanja novog registratora postavi 'na polici'-'na polici' obzirom da se mora unijeti vrijednost pozicije. U ovom slučaju bi se morao mijenjati i kod za dodavanje inicijalne vrijednosti...

Dobro primeceno. tacno, ako se zahteva pracenje pozicija na policama, onda se mor amenjati kod za inicijalni red. To nije strasna promena, ali sve ostalo jeste.

Najstrasnije je sto se na nivou tabela ne moze garantovati da na jednoj poziciji nema vise od jednog registratora. Kod za tu proveru, opet, nije tesko napisate. Ali, sta ce se desiti, kad je pred vama ocigledno slobodno mesto, a u bazi pise da na to slobodnoj poziciji sedi neki registrator X. Gde je tacno registrator X? Bez gledanja i trazenja ne mozemo znati. Ili, zamisli da u bazi pise da je neka pozicija prazna, a tamo sedi neki registrator Y. Gde je u stvari registrator Y? Razumna opcija po meni je da na policama postoje definisna mesta za svaki registrator, i da se svaki registrator uvek stavlja na svoju poziciju i ni jednu drugu. Ako pak nemate dovoljno mesta na policama za sve registratore, onda ni pracenje tacne pozicije nema smisla jer ce uvek biti registratora koji su vraceni, ali nema mesta na polici za njih.

U bibliotekama u Toronto to je reseno tako sto na svakoj knjizi stoji labela koja je jedinstvena i oznacava pribliznu poziciju knjige - policu i sprat na polici ili tako nesto. Kad vracam knjige, samo ih bacim na gomilu. Onda osoblje biblioteke svaku knjigu odnese na njeno mesto. I taj proces uglavnom funkcionise, iako se desi da u bazi pise da je knjiga tu, a nema je na polici. Mozda je zaturena, ukradena, pogresan unos u bazu - sto i jedan razlog - uglavnom, nema knjige na njenom mestu. Inace, sistem je potpuno automatizovan. U gradu postoji stotinak ogranaka, svaki sa razlicitim knjigama. Bilo koju knjigu, iz bilo kog ogranka, mogu da narucim preko interneta, i ona ce biti donesena u biblioteku koju odredim, cim bude raspoloziva (mozda je neko drugi drzi u momentu podnosenja zahteva). Ako hocu da produzim rok drzanja knjige, to sito radim internetom ili telefonom, i to s eodbrava automaski, osim ako je tu knjigu neko narucio i ceka je. nema ogranicenja koliko knjiga mogu da podignem

Neke probleme nije prakticno resavati bazom podataka.

@salvatore ostale su neke nejasnoće (makar meni):
Meni je u svemu najmanje jasno šta se dešava kada je registrator oštećen? Šta se tada dešava sa "karticama" koje su u njemu? Da li se formira novi registrator sa novim brojem pa se sve kartice prebacuju u njega a za taj se evidentira šta se od njega može iskoristiti za novi i to se iz njega odvoji za pravljenje novog registratora a oštećeni dio se baci, jer zašto bi čuvali oštećene dijelove? Kako onda evidentirate to prebacivanje kartica? Ako novi nasleđuje broj od starog kako onda taj stari evidentirati u oštećene?
Kako se uopšte vodi broj registratora?
Ako se odmah na mjesto izdatog registratora na policu stavlja neki iz rezerve, znači da kada se registrator vrati nema mjesto na polici već mora ići u rezervu?
Iz dosadašnjih objašnjenja saznali smo da su moguća 4 statusa registratora: na polici, izdat, rezerva i oštećen
-Kad je 'na polici' treba da ima atribut pozicija(broj police + broj mesta)
-Kad je izdat ( Korisnik, broj kartica prije izdavanja) - ovde je pitanje kad se upisuje koliko je imao kartica kad je vraćen ?
-Rezerva( @salvatore je rekao da se vode kao i kad su 'na polici') pitanje da li se baš tako mogu voditi?
-Kad je oštećen gore sam postavio pitanja.
-Mislim da ovde hvali još mogućih pozicija registratora??? Šta mislite koji status uzeti kao inicijalni - početni?
Prije nego se pokuša išta napraviti mora se do tančina definisati svaki detalj, da bi ga prenijeli na aplikaciju.

Ja se od samog starta nisam lepo izrazio. Nije u pitanju prava arhiva, zvanična sa dokumentima, projektima... Ovo kod mene je jedan izolovani slučaj kakav nećete naći nigde. U svrhu ove teme, pretpoostavljam da je puno bolje da se moj slučaj ne uzima za pravilo.

Prava reč bi možda bila kartoteka. Kod mene rezerva ne znači rezervni registratori, već je to rezervno mesto gde takođe držim registratore koji su u upotrebi. Oštećeni su skoro pa i nebitni, pošto ih ima samo par (uklapamo oštećene, šteta da se baca). U pravoj arhivi ili kartoteci su pretpostavljam važne neke druge stvari... Meni je važno da oni koji se više koriste budu bliži meni, red i pravila određujem ja...

Možda bi ovu temu trebalo razvijati u nekom drugom pravcu (da ova tema bude korisna većem broju ljudi a ne jednom jedinstvenom slučaju)

@salvatore jasno ste u prethodnim postovima objasnili da se ne radi o klasičnoj arhivi. Zbog toga da bi se u pravom smjeru realizovala ova aplikacija važno je da striktno uspostavite pravila koja u njoj važe prije nego se pristupi realizaciji.Morate uočiti sve slučajeve upotrebe i uspostaviti pravila po kojima se ovi slučajevi moraju izvoditi.

Ništa nije nebitno. Ako postoji pojavni oblik (odn. status Oštećen) moraju se uspostaviti tačna pravila šta se u tom slučaju dešava. Aplikacija treba da podrži ta pravila i mora se znati na koji će se način aplikacija uklopiti u ta pravila.

Aplikaciju možete realizovati čak i da Vam na osnovu broja korišćenja predlaže i položaj registratora (da Vam budu bliži ), sve zavisi od ideje šta želite postići sa aplikacijom , ali opet da bi se išta odradilo kako treba mora se striktno definisati svaki slučaj upotrebe- i to prije realizacije.

Ova tema je već korisna većem broju korisnika, i mislim da je @Zidar već prikazao ono što je želio ovom prilikom prikazati i čemu nas je želio naučiti. Ova moja pitanja i potpitanja su više kao savjet Vama o čemu bi dalje trebali razmišljati ako ovu aplikaciju želite privesti namjeni onako kako Vama odgovara.
Sve u svemu sjedite i razmislite o svim slučajevima koji se javljaju,i jasno ih definišite prije nego nastavite, da bi Vam oni koji imaju vremena i volje mogli dalje pomoći u pravom smjeru .... To Vam je moj prijateljski savjet. Pozdrav.

Da, ja sam puno naučio prateći temu, dosta sam naučio čitajući i odgovarajući na postavljena pitanja. Neprijatno mi je što zbog nivoa znanja u ovoj temi ja najmanje učestvujem, trenutno analiziram ovo što je do sad urađeno pokušavajući da shvatim i naučim.



Sve je tako, novi registrator uvek dobije novi broj, a u napomenu napišem broj starog koji je "nasledio".



U trenutku kada sam ja dohvatio tog posla sve je bilo u haosu. Pokušavam da uvedem red.




Da



Da, pomislio sam da taj atribut može kreirati ovako: 00012 (000 - broj police; 1 - red; 2 - mesto).



Uz registrator dobijem i ceduljicu sa izmenama, proverim i ispravim ako treba.



Dovoljno je i promena osnovnog stanja, ove dodatne komplikacije sa pozicijom bi već bile luksuz.



Početni status je u redu da bude "na polici" ili "rezerva" svejedno.

Moze se odraditi. U ovom slučaju primjenjuje se trik. Uvodi se polje koje će prikazivati podatak(ono koje će se vidjeti), a za izvor combobox-a će se postaviti uslov da ne prikazuje podatak koji je već u upotrebi (u izboru combobox-a neće biti vrijednosti koje su već u upotrebi).
Ako ovu vrijednost postavljate kada je status registratora 'na polici' tada će se morati voditi računa da se ova vrijednost oslobodi kada registrator uzme novi status, da bi se vrijednost oslobodila za registrator koji će zauzeti njegovo mjesto- da bi se ta vrijednost pojavila u combobox-u za izbor mjesta na polici.
Osjećam da se sad pitate šta li sam sad ispričao,he,he...
Pokušajte raditi primjere onako kako umijete pa ćemo ispravljati.

Imao sam malu pauzu na (ležao malo na VMA), pa nisam imao pristup računaru. Učim access u slobodno vreme, ali je moje znanje još uvek nedovoljno.

Pitanje:

frmRegistratori (kada otvorim Form View) ima u subformi kolonu "TrenutakPrelaza". Kada isti "form" otvorim u "Design View" pomenutog "trenutka" nema... Jel može neko da mi objasni?

Skroluj subformu.

Ja nisam razumeo.... Našao sam... Toliko je očigledno da ne mogu da verujem da nisam video...

Evo sad videh sledeći problem... U subformi (frmRegistratori) imam kolone: Rb, TrenutakPrelaza, NovoStanje i SifraRadnika. Kada istu otvorim u Design View vidim: Rb, StariRb, BrojRegistratora, TrenutakPrelaza, PrethodnoStanje, NovoStanje, StariTrenutakPrelaza i ŠifraRadnika.

Verujem da su nekom ova pitanja smešna. Smešna su i meni kad čujem odgovor... Šta da se radi.

_{[Ovu poruku je menjao salvatore. dana 12.03.2014. u 13:13 GMT+1]}

Na fomi se vidi samo ono sto korisnik treba da vidi. Sve ostalo je nevidljivo ili sakriveno. Korisnik sistema ne mora I ne treba da zna niti vidi onu kompleksnu strukturu sa prethodnim stanjima, prethodnim rednim brojevima I prethodnim vremenima. Ta su polja nevidljiva ili sakrivena, ali su na formi - jer nam trebaju da u njih unesemo podatke. Korisnik unese TrenutakPrelaza I NovoStanje I onda se aktivira kod na nekom eventu koji popuni tabelu promena stanja. Taman posla kad bi od korisnika ocekivali da sam popunjava tu tabelu, bilo bi gresaka na tone. Korisnika na ovaj nacin, skrivanjem kompleksnih psotupaka, stitimo od gresaka I komplikacija.

Nadam se da je zdravlje u redu ili barem bolje nego pre VMA.

Srecno!