Pracenje promene statusa nekog objekta (Baza za vođenje arhive)

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



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.

:-)