Nije valjda da niko ne zna odgovor?
Evo baza u prilogu pa molim da pogledate.

Najveći broj tabela je bez primarnog ključa (pogotovo šifarnici), te je otud nemoguće ispratiti povezivanje u relacionom modelu. Moguće je da će greška nestati kad se ovo ispravi. Ključ u tblRacunStavke ne može biti RedniBrojstavke + RacunBroj, već obrnuto RacunBroj + RedniBrojStavke.

Dodao sam kljucve u tabele koje nisu imale i zamijenio sam kljuc u tblRacun...sada je RacunBroj + RedniBrojStavke. Nazalost, ali problem se nije rijesio sam od sebe.

Pogledao sam vas model baze i u potpunosti se slazem s kolegom @Getsbi. Imajuci u vidu navedeno, postavio sam sebi pitanje zasto ste uopste radili ovu bazu u Access-u kao predstavniku relacionog modela. Morali bi pre svega da predefinisete model ako vec radite bazu u relacionom modelu. Da ne bi ispalo da se samo prica, malo sam zasukao rukave i korigovao model onako kako bi trebalo otprilike da izgleda. Sve ostalo je onda prica posle.



_{[Ovu poruku je menjao Zoran.Eremija dana 05.04.2010. u 11:44 GMT+1]}

Sve stoji u napred poslatim postovima,ali evo ti pa vidi da li ovo može pomoći.

Hvala svima...

Natjerali ste me da uraim ono sto odugovlacim mjesecima.Da li je to sada treca normalna forma ili neka druga nije vise ni bitno, ali i meni se svidja.

To je to Sloj.1973 ali da pitam prvo da li bi mogao da stavim u neku funkciju npr.

Select Case Screen.ActiveForm.Name
Case "Racun"

pa da iz nje otvorim pretragu
i da naguram u tu funkciju onda sve forme koje zelim filtrirati...
Ne znam mozda sam sada i lupio ali mi izgleda logicno.

Drago mi je da smo pomogli. Kada budete imali vremena pokusajte da proucite model koji sam vam nalepio "...KakoBi". Ako biste ga primenili manje biste kodirali vecinom bi sve resavali putem upita.

Evo kako sada izgleda model baze, mada sada slijedi testiranje kojim zelim da obuhvatim sve situacije iz realnog poslovanja.Aplikacija je zamisljena za Veleprodaju, maloprodaju i komision.
Ono sto me malo buni jeste upravo poslovanje komisiona, jer jedan artikal moze da donese na komisionu prodaju vise komintenata, po razlicitim nabavnim cijenama, a istom prodajnom.Znaci treba pamtiti ako imam isti artikal od vise razlicitih dobavljaca, koji je od koga stigao i koliko komada (isto tako i za prodaju) zbog buduceg finansijskog poravnanja, odnosno isplate za prodatu robu.Ako neko zna kakav model za komision nebi bilo lose da prodiskutujemo o tome.

E ovo je vec druga dimenzija na prvi pogled... Ako nemate nista protiv malo bih prilegao... Samo imam jedno pitanje. Zasto svakoj tabeli dodelujete u nazivu ono na pocetku "tbl.....". Zar to nije suvisno kucanje, koje se kasnije multiplicira vremenom?!?! isto vazi i za "frm..." pa "qry..." i da ne pitam dalje.

^ MS Access: LESZYNSKI (HUNGARIAN) NAMING CONVENTION

Wikipedia: Leszynski naming convention

MSDN: Visual Basic Concepts Object Naming Conventions



_{[Ovu poruku je menjao Take 5 dana 06.04.2010. u 00:38 GMT+1]}

Lepa Konvencija znam ali UBI BRATE... Hvala na konvenciji jos uvek sam dovoljno lenj... :-)

I mene mrzi da kucam uvijek tbl, frm, qry...ali po meni to ima i dobrih i losih strana.Dobra je ta sto uvijek vidis gdje sta pripada, a losa sto zna napraviti takvu pometnju kod referenciranja da ti se smuci i access i cijeli zivot.Npr zaboravis prefiks da napises i kontas sta nisi dobro uradio, a ono ne vidis sumu od drveta. -:)

Sta bi za komision zna li ko model za komision?

@Golic, za poslove tipa Komisione prodaje nemam bas neko iskustvo. Samo znam da je jako vazno da li se roba gleda komadno ili kolicinski.
Malo sam sinoc pogledao model mogao bi jos da se optimizuje posebno imajuci u vidu na pojavu vise entiteta "tblDokument", "tblRacun", "tblIsplataKomitenta",... koji su dokumenta i moglo bi da se generalizuju kao generalizovani entitet.

I ja sam razmisljao u tom smijeru i sad kontam kakvi sve dokumenti izlaziti iz baze...
Predracun
Avansni racun
Maloprodajni racun
Veleprodajni racun
Veleprodajni racun Usluge
Ugovori
Povrat roba
Isplata komintenata
Prelokacija/Predisponacija artikla
Otpremnica
Narudzba
Omisljam se da li zasebno napraviti tabelu nivelacija roba ili i nju svrstati u tblDokument.

Takodje sam dodao i tabelu tblVrstaPartnera sa poljima VrstaPartneraID(spoljni kljuc tblPartner), NazivVrstePartnera i Rabat.
Planiram da pripojim aplikaciji tabele o vodjenju evidencije o radnicima i ovom prilikom da pitam Getsbi-ja da li je njegov model baze za finansijsko koji je svojevremeno bio na Icentru postao javno dobro, pa ako jeste da i njega prikljucim u projekat.

Sve moje što okačim je javno vlasništvo.

Icentar je ugašen. Model se može skinuti ovde: http://www.elitesecurity.org/t291202-0#1742519

E sada je konacno pravo razmisljanje izneto i pravi problem. Preporucio bih vam da prvo identifikujete sve radnje-poslove koje mislite da automatizujete i svakako sve dokumente. Pretpostavio sam to da cete morati uraditi, jer da bi se pratio sistem to se mora. Kada sve to identifikujete ond apristupite kreiranju modela. Preporucio bih vam da za kreiranje koristite alate (npr ERwin) jer cete sebi olaksati rad. Na osnovu poslednjeg vaseg posta sve mi se cini da ce vam model biti sa najmanje 200 entiteta-tabela. To ne treba da vas plasi. Kao sto vidite i sami navodite “Omisljam se da li zasebno napraviti tabelu nivelacija roba ili i nju svrstati u tblDokument” sebi pitanje.
Postoji model-koncept Generalizacije i specijalizacije koji se primenjuje u takvom slucaju. Sve one osobine koje je su zajednicke za sva moguca dokumenta stavljaju se u generalizovani dokument "tblDokument" (ovo oko konvencije pisanja tbl ... nemojte se muciti samo sebi stavljate omcu oko vrata), a ono sto je specijalno bio bi "Racun", "Nivelacija", "ObracunIsplate"... Upravo pokusavam da vam pojasnim na vasem modelu. Nije mi jasno zasto u tblRacunStavke stavljate atribut RedniBrojStavke a ne "SifraArtikla", na ovaj nacin dozvoljavate da u stavkama jednog racuna moze korisnik da unese 100 puta isti artikal. Ima ovo smisla u nekim slucajevima ali ima i problema, te vas zato pitam?
Takodje Partner, komitent, Banka sve je to isti ucesnik u sistemu samo ima razlicite uloge. Uloge definisu u zavisnosti poslovne saradnje, a ona se jasno definise dokumentom. npr. Banka moze biti dobavljac i kupac i banka...sve jedan te isti. Jos jedno zapazanje, cesto se u imenovanju tabela a ja volim da kazem identifikacija entiteta koristi pojam "Artikal", "Sifarnik", "Roba" i to se vezuje za stavku racuna. Kada se daju imena entiteta (priznajem da mi je to dosta tesko nekada) treba voditi racuna da asociraju na realni sistem. Ako ce u tu tabelu uci jedna n-torka "Viskic 0.05" ima smisla, a ako ce uci "Posluzenje viskica s hledom" onda ovoo nema nikakve veze s robom ili artiklom, mozda sa sifarnikom. Pokojni Pera Petrov prof sa Masinskog Fakulteta u Beogradu je svojevremeno govorio o pojmu "Predmet poslovanja".

Postojanje entiteta "StopaPorezaStavka" je uredu. Jedan porez ima više stopa. Ista stopa može biti u više poreza. Ja bih ga ipak ostavio kao projektni (bez sopstvenih atributa). Pogotovo mu nebih dao atribut "IznosPoreza".

Ja sam stavio ovako pa kako bi da bi...

Imam dobar šifarnik koji ja koristim,i sigurno nema boljeg u access-u.Probajte

Uh, stvarno je dobar :) Hvala puno na ovome!

Svaka čast, hvala!

Ako se prethodna dva komentara odnose na pomenuti šifarnik, koji je postavio Miro35, onda meni baš ništa više nije jasno u vezi Accessa!
(ili sam možda izgubio smisao za šalu?)

Ja nemam kriterijum u vezi sa accessom čovek je podelio nešto što šljaka i iz čega ću ja moći da nučim neku foru a kada budem iskusniji možda ću se složiti sa vama!

Ne verujem da išta korisno može da se nauči iz "access baze" koju čine dve tabele, bez definisanih relacija, primarnih ključeva i ostalih najosnovnijih stvari...
????

Jedno od dobrih, mesta za početak učenja (i usavršavanje) je Office Praktikum: MS Access

Izbor uvodnih članaka:

Kako napraviti Access aplikaciju

Saveti za efikasan rad

Saveti za efikasan rad, drugi deo - VBA

Podelite MDB datoteku na podatke i aplikaciju

...


Trenutno ima više od 100 korisnih, sistematizovanih članaka, kako za totalne početnike tako i za naprednije korisnike...




_{[Ovu poruku je menjao Take 5 dana 08.04.2010. u 02:18 GMT+1]}

@ Take 5
Koliko sam ja shvatio Miro35 je izvukao iz svoje aplikacije deo koji se odnosi na pretragu i to je prikazao. Pretenzije mu i nisu bile veće.

Baš tako, i moj komentar se naravno odnosi samo na sistem za pretragu šifarnika koji je postavio Miro35.
Meni se sviđa. Brz je i efikasan, ne zahteva mnogo dizanja ruku sa tastature i hvatanja miša, tj odličan je za operatere koji odgovaraju na telefonske pozive, itd.

Ima dosta dobrih caka, koje ću rado upotrebiti u svojim aplikacijama. Ne vidim da tu ima išta sporno?



_{[Ovu poruku je menjao smal dana 08.04.2010. u 09:53 GMT+1]}

@Getsbi: Siguran sam da si u pravu, tek sada vidim o čemu se radi.
Prilikom prvog pokretanja baze, kada sam video samo dve tabele, bez definisanih relacija, PK, i svega ostalog nisam se dalje zamajavao priloženim uzorkom.

PS
Napomena početnicima u vezi učenja iz priloženog uzorka, stoji i dalje...

Take5, hvala za linkove.

Jeste postavio sam samo pretraživač iz svoje aplikacije.Ja sam isto dosta vremena tražio ali ovaj sam našao na nekoj stranici ne znam na kojoj.Posebno je dobar zato kad ukucavate ili tekst ili brojeve,on filtrira podatak i po šifri i po nazivu,ne znam jeste li to primjetili.

Još nešto,vidim pišete o primarnim ključevima i relacijama.Sve to stoji i školski je da se rješe te stvari u bazi,ali isto tako gledajte da se stave kontrole(poruke) da obavjeste korisnika vaše aplikacije da taj podatak već postoji ili tako nekako.Jer morate u svakom slučaju da izbjegnete access poruke na engleskom,ili npr. da vam blokira aplikacija zato što je proradio primarni ključ.

Nije to samo školski, već je to nešto što se zove "dobra praksa", i što ljudi koji znaju svoj posao ponavljaju sa veoma dobrim razlogom. I svakako je daleko bolje da aplikacija pukne ili da prikaže poruke na engleskom, nego da đubre završi u bazi...

Evo ja svakodnevno muku mučim sa DBF tabelama koje moram da koristim u firmi, jer nemaju relacije na "fizičkom" nivou, PK, referencijalni integritet i ostalo što imaju modernije baze. Svako malo se ponegde pojavi duplirana šifra koja tu nikako ne sme da postoji, null vrednosti koje nisu dozvoljene i sl... pa mi toliko s*ebu koncepciju da ne znam šta da radim, iako su aplikacije radili vrhunski programeri i to teoretski ne bi trebalo da se dešava, jer je sve iskodirano kako treba i sve greške su kao presretnute...

Mislim da razumem muku koju Miroslav ima. Ali se ne slazem sa resenjem. Svrha primarnog kljuca, i onog drugog, stranog JESTE da blokira aplikaciju ukolliko se pokusa unos losih podataka.

Tacno je da Access daje poruke na engleskom kada se narusi PK ili FK (foreign key, strani kljuc). Postoji nacin da se te poruke prevedu. za to se koristi formin Error event.

Evo primera:



Ako se ovo primeni, poruke vise nece biti na engleskom i Miro ce moci slobodno da koristi PK i FK, bez straha da ce mu to blokirati aplikaciju.

Da li je moguce napraviti funkciju koja bi ovako prevela sve greske
pa je onda pozivati na error event svake forme, i koristiti u svakoj buducoj aplikaciji? Da li je ovo uopste izvodljivo?
Da li je moguce ovako prevedene opise greske upisivati u ErrorLog tabelu?

Mozda lokalne verzije Accesa imaju poruke o greskama na lokalnim jezicima? Ako srpska verzija ima poruke na srpskom, onda ti ne treba funkcija.

Negd eu temi Baza Znanja postoji kod koji izlistava sve Access greske, koje se mogu uhvatiti sa On ERROR GOTO. Kod pravi tabelu sa svim kodovima gresaka i onda se moze dodati kolona sa prevodom. To bi bio veeeliki posao jer poruka o greskama ima mnogo. Resenje bi bilo da se u SVAKU funkciju i proceduru i even-proceduru koju napises ubaci ERRROR HANDLING kod (sto je i inace dobra praksa). Onda se u okviru errro-handling poricita kod greske, pa se na osnovu koda procita tekst poruke koji smo preveli i spakovali u tabelu gresaka.

Medjutim, nesu sve greske run-time greske. Primery Key, Foreign Key greske, narusavanje validtion rules nisu run-time greske, pa se ne nalaze u pomenutoj tabeli. Za nekoliko najcescih non-run-time gresaka pise se kod koji sam dao u poslednjem postu na ovu temu.

Sve u svemu, teorijski moguce i pozeljno, ali prakticno tesko ostvarljivo. Mnogo je lakse uzeti verziju Accesa na lokalnom jeziku.