Koliko vidim nisi napisao šta da ti f-ja Nz vrati u slučaju da je polje null vrednost. Znači (npr.):

Pokušao sam to i ništa, a pokušao sam i ovo:

=IIf(Nz([FrmRezervacije].[Form]![SumRazlika]) Is Null;0;Nz([FrmRezervacije].[Form]![SumRazlika]))



_{[Ovu poruku je menjao pmiroslav dana 03.10.2007. u 14:57 GMT+1]}

Probaj ovako:



Ako ti je windows podesen na engleski onda umesto ; ide ,

Nije problem u zarezima

Ok, nego, ako se dobro sećam treba Forms.[Ime forme] a ne [Ime forme].[Form]! Davno sam radio u accessu pa ja to po sećanju

Tacno, nije problem u zarezima. Fpedja je napisao korektan izraz, tvoj izraz glasi:

=Nz([FrmRezervacije].[Form]![SumRazlika])

Treba

=Nz([FrmRezervacije].[Form]![SumRazlika],0)

Nadam se da primecujes razliku. Tebi nediostaje zarez i nula u funkciji Nz.

I u ponovnom pokusaju napravio si istu gresku:

=IIf(Nz([FrmRezervacije].[Form]![SumRazlika]) Is Null;0;Nz([FrmRezervacije].[Form]![SumRazlika])ovde fali zarez i nula)

a treba

=IIf(Nz([FrmRezervacije].[Form]![SumRazlika]) Is Null;0;Nz([FrmRezervacije].[Form]![SumRazlika],0))

Ja sam dodao ,0 (bold)

Nadam se da je pomoglo.

:-)

Sada sam kod kuće, a baza mi je na poslu.
Pokušat ću sutra sa ovim korekcijama.
Iako mislim da nije u tome problem i da sam pokušao i sa 0 na kraju.
Meni se čini da je problem možda u tome što je subforma u obliku Datasheet i kada za nju nema podataka ni jedan red u njoj se ne vidi pa funkcija nema odakle uzeti podatak za računanje.

Nisu mi pomogle gornje sugestije.
U prilogu šaljem primjer baze pa molim nekoga da mi pomogne ako može.

Mioze li ZIP umesto RAR?

Pazi, tabele ti nisu dobre. Nemaš veze izmedju tabela niti definisane ključeve za svaku tabelu. Možeš li malo da objasniš proces? Pošto sam na poslu pa nemam baš vremena da istražujem a želeo bih da ti pomognem

Pakovanje za Zidara.

Hvala Getsbi :-)

Odakle da pocnem?
1. ne postoje relacije => nema integriteta podataka
Otuda u tabelama Ulaz i Izlaz materijali koji nisu definisani u tabeli Materijali.
Otude kveri 'Ulaz robe' ne radi korektno, trba LEFT JOIN
Kveri 'Ulaz Robe' je ulaz za kveri Stanje iz koga bi Dlookup mogao da cita stanje za svaki tekuci rekord na formi, umesto da cita iz subformu. To kad bi 'Ulaz Robe' bio koraktam kveri, ato ne moze iz razloga nepsotojanja data integrity. Drugo, kveri Stanje ima lose napisanu formulu za racunabje stanja

Ponovo nedostaje nula u Nz([IzlazUkupno]), treba Nz([IzlazUkupno],0)

I ponovo ce Miroslav da kaze - hvala na savetima ali nije to, probao sam. Da si probao, ne bi i dalje bila greska u formuli :-)

S obzirom da Miroslav ne zna osnovne stvari - integritet podataka i dobijanje stanja na osnovu korektnih kverija, pokusao je da se snadje 'pomocu subformi i Dlookup i NZ funkcija' koje takodje ne zna da upotrebi.

Koliko mi svi vremena treba da izgubimo pokusavajuci da nadjemo gresku kad je sve pogresno. Nije uradjena baza, a aplikacija je nakaradno postavljena. Subforme se koriste za nesto drugo, a ne za citanje podataka koji bi se prikazali na glavnoj formi. Znaci, nismo nacisto ni sa upotrebom subformi. Da rezimiramo: back end ne postoji, fornt end zamisljen neuko uz nepoznavnaje osnovnih funkcija.

Mi tu mozemo pomoci samo upucivanjem na top temu Korisni Linkovi pa da se nadje tutorijal. I da se naravno u top temi 'Ako dolazite prvi put na forum' procita prilog koji je Getsbi dodao juce. Ali, i tu ima napomena. Niko nije postao ni inzenjer ni doktor uceci iz tutorijala na webu i pitajuci po forumima. A posto su programeri placeni otprilike kao doktori i inzenjeri, verovatno da i moraju da sticu znanje barem onoliko dugo kao doktori i inzenjeri.

Ako ste samouko naucili dve tri stvari u Accesu, ne pokusavajte da pravite aplikacije. Ili nam posteno kazite - ucim se, ne znam odakle da pocnem. Pa kad kazemo 'procitaj neku knjigu o dizajnu baza podataka' shvatite to ozbiljno. A to traje. Niko nije naucio dizajn baza za nedelju dana. Tek onda mozemo da govorimo o gradjenju aplikacija i specificnostima Accessa. Sve ostalo je gubljenje vremena. To sto vam Microsoft kaze 'Congratulations, you have just built your first form by using Wizard' - okacte macku o rep. To je marketinski trik da bi veliek firme na zapadu i vlade kupovale licence za Access i stavile na sto svakom sluzbeniku. To soto vam je neko kupio Access ili imate ukradenu kopiju ne cini nikoga programerom a sigurno necete nauciti ovaj posao na forumu.

Procitajte sta je Getsbi napisao, pa tako postavljajte pitanja ako ste pocetnik i imate veliku ideju o aplikaciji.

Sada ste me do kraja postidili, a ja sam mislio da znam nešto malo o Accesu.
Stvaro priznajem da nisam programer, ali sam napravio par aplikacija koje nisu idealne, ali koje mi pomažu u radu.
I ovako na forumu tražim pomoć vas iskusnih majstora da one bolje rade.
A što se tiće relacija i indexa, ovo je dio jedne veće baza koju sam za ovaj primjer koji sam poslao, na brzinu skratio da istaknem samo primjer koji me mući. U kompletnoj bazi oni postoje.
Ovu karticu ja za sada bolje ne znam napraviti, a možda hoču ako mi pomognete.

_{[Ovu poruku je menjao pmiroslav dana 04.10.2007. u 19:18 GMT+1]}

I da je deo neke baze, kad inportuješ tabele one ostanu povezane osim ako nisu linkovane, a ove nisu. Od pet samo dve imaju primarni ključ, a to se takođe prenese importom.

Nego da te ne kritikujem previše. Ako hoćeš da ti pomognemo, pomozi i ti nama. Nemoj da nam izručiš gomilu po kojo mi treba da preturamo i tražimo greške. Jednostavno skrati fajl na najmanju moguću meru (utroši malo vremena za to), tako kao da želiš da nekom predočiš svoj problem na najbolji mogući način da prosto bude efektno i uočljivo. Razmišljaj da su s druge strane ljudi koji imaju isto tako malo vremena kao ti, ako ne i manje. Ko god vidi, nesme da pobegne od toga već da ga zainteresuje problem.

I da ne ostaneš bez odgovora. Ovo se u normalnom povezivanju forme i pidforme ne dešava. Problem je nastao nasilno. Ne mogu ovde da držim predavanje o tome ali bi bilo dobro da kreneš postupak iz početaka i poštuješ sva pravila koja si do sada naučio o Accessu.

Evo malo sam u međuvremenu poradio na svojoj bazi pa molim da sada date svoje mišljenje.

Resenje je sada malo bolje nego ranije, ali jos ne dovoljno dobro.

Mislim da back end nije kompletan. Obicno se pravi posebn tabela za ono sto zoves Predatnice i Otpremnice. Moze po jedna za svaki document, a mogu se is vi dokumenti strpati u jednu tabelu, uz poznavanje tipa dokumenta. Preporucujem ti posebnu tabelu za svaki document dok malo ne steknes iskustva. Posle mozes i sve da spojis u jedno, ima prednosti ali i mana. Kad naucis prednosti i mane i kako da ih iskoristis, onda ima smisla trpati sve u jednu tabelu. Dotle, svaki document neka ima svoju tabelu. U tim tabelama pise identifikacioni broj dokumenta (predatnica ili otpremnica), datum izdavanja, od koga je (predatnica) za kogaje (izdatnica) i slicno. Onda se naprave tabele za stavke na dokumentu. To imas, to su tvoje tabele Ulazi i Izlazi. Trebalo bi da imas ovakvu situaciju u relationship dijagramu:

Otpremnice------< Izlazi >------ Artikli
Prijemnice-------< Ulazi >------- Artikli

gde je znacenje Roditelj---< Dete >---- Drugi Roditelj

Odnos Roditlej-Dete medju tabelama se po pravilu modelira kao Forma(Roditelj)-subforma(dete). U ovom slucaju ima sdva roditelja, sta da se radi? Jedan od roditelja je vazniji u ovom slucaju. Ako razmislis o kardinalnosti relacija, videces da moze da postoji Artikl i da se nikad ne pojavi na priejmnivi niti na otpremnici. Znaci, za desnu stranu prikazanih relacija medju tabelama, imam kardinalsnost 'nula ili vise'. Na levoj strani imamo kardinalsnost 'jedan ili vise' (pretpostavljam da nema smisal u bazi cuvati Otpremnicu koja nema ni jednu stavku, otude ono 'bar jedan ili vise'). Ako ne mozes iz poznavanja logika poslovnog procesa da zakljucis koji par forma/subforma je potreban, pogledaj kardinalbnost. Ako je kardinalnost 'nula ili vise', onda ti ne treba forma/subforma. Proizilazi da ces imati forma/subforma konstrukciju za Otpremnice/Izlazi i Prijemnice/Ulazi

Elem, onda bi se za Otpremnicu i Predatnicu napravile forme, svaka sa svojom subformiom gde bi se vrsio unos. Dakle, imao bi (frmOtpremnica + subformIzlazi) i (frmPrijemnica + subformUlazi) Za aktiviranje formi frmOtpremnica i frmPrijemnica napravio bih dva dugmeta, "Nova Otpremnica" i "Nova Prjemnica" koja rade upravo to - otvore frmOtpremnica i frmPrijemnica i cekaju unos. Dugmad stavis na ono sto je tvoja glavan forma trenutno.

Na formi koja ti se otvara sa otvaranjem aplikacije imas dugme 'pretrazi' koja otvara datasheet za pretrazivanje. Ja bih licno ostavio datsheet za pretrazivanje stalno vidljiv. Tu bih prikazao trenutno satnje svih artikala. Imas dakle sve article pred sobom i njihovo stanje. Svi stalno kukaju kakozele kombo box, pa da izebru artikl I vide stanje. Ne treba kombo box, ne treba biranje, sve ti je pred ocima stalno. Mozes da sortiras, filtriras, biras po nazivu, sifri, dobavljacu, vsrti, dimenziji, po cemu god hoces a sve bez i jedne linije koda. To se naravno slaze sa teorijskim radovima velikih majstora Zidara i Chacke. Naime, Zidar je postavio teoremu da je 'the best code is no code at all' a onda je Chachka dokazao da je u pitanju u stvari aksioma. A o aksiomama se kao sto znamo, ne diskutuje. Osim ako ne zelite da dokazete da se paralene prave seku negde dovoljno daleko I da psotoji trougao sa tri prava ugla (zaista se moze pokazati da je sve ovo tacno)

Imao bih takodje datasheet forme gde bih mogao da vidim sve postojecde prijemnice/otpremnice. I onda bih klikom na identifikacioni broj dokumenta otvarao postojeci document da ga vidim ako treba i menjam nesto ako zelim. Naravno, da bi pozvao datasheet forme koje listaju sve otpremnice I prijemnice, trebaju nam dugmad, "Prijemnice" i "Otpremnice". I svi ovi dugmici treba da budu na tvoj trenutno glavnoj formi .

Za pohvalu:
Svidja mi se resenje sa pozivanjem reporta iz posebne forme, koja u stvari cita nazive reporta iz neke tabele. Tu dobijas na fleksibilnosti. Kad god napravis novi report, samo ga dodas u tabelu I list box ce ga prikazati. Tu ima jedna mogucnost poboljsanja. Reporti nekad traze neke parameter pre nego sto ih otvorimo. Na primer, zelimo nesto ali u zadatom datumskom opsegu. Postavljanje parametra u kveri je za nekoga ko ne ume da programira. Kou me I voli da programira, on napravi formicu gde se zadaju parametric, pa se odatle otvori report jednostavnim DoCmd sa Where uslovom. E tu imamo mali problem. Kako da znamo da li otvaramor eport direktno ili preko forme? Razmisli malo, postoji resenje. Naravno, resenje nije u programiranju nego u strukturi tabele koja cuva nazive reporta. Dodas jedno polje, true/false i nazoves ga IsForm, default = FALSE. Ako za neki report zelis da otvoris formu za gradjenje kriterijume, u tabelu uneses ime forme i stavis IsForm = TRUE. E sad dolazi programiranje, umesto OpenReport, proveris da li je ISForm=TRUE i ako jeste radis DoCmd.OpenFor "tvoja formica za gradjenje kriterijuma na kojij je dugme za print/preview report". Eto, imas dosta da radis.

Zidar hvala ti na opsežnom odgovoru i sugestijama.

Imama jednu dilemu.
Da li je bolje upis ulaza i izlaza iz skladištu unositi u dvije različite tablice. Ili je bolje u jednu tablicu koja bi imala polje ulaz i polje izlaz.

Ako se odlucis za jednu tabelu sa dva polja, Ulaz i IZlaz, onda moras da obezbedis da u svakom redu tacno jedno polje ima vrednost nula a drugo da ima vrednost vecu od nule. Drugim recima dve nule zabranjeno, dve vrednosti razlicite od nule, takodje zabranjeno. Dalje, ako odlucis ovako, moraces da imas jednu tabelu za sve (oba) dokumente, i da naznacis tip dokumenta.Inace neces imati dada integrity. ne moze da se postavi relacija gdena isto polje u dete tabeli imas dva roditelja, a tebi bi to trebalo. Stvari se dakle mnogo komplikuju ako imas jednu tabelu sa dva polja ulaz/izlaz. veoma iskusni programeri iz pred relacionih vremena ovo mogu da razrese odgovarajucim programskim kodom, ali ostaje probelm da nije obezbedjen integritet podataka na nivou tabela.

U prethodnom postu sam ti preporuco da imas posebne parove tabela (Prijemnica--<Ulaz) i (Otpremnica--<Izlaz)
nemoj sebi da nepotrebno komplikujes zivot. tabela cuva ili ulaz, ili izlaz, jer tabela treba da cuva jednu klasu objekata. Ulaz i izlaz su prilicno razliciti po svojoj prirodi, iako izgledaju veoma slicno.

Ova opcija sa dva polja stoji jedino u slučaju da imaš dokument po kojem ti roba i ulazi i izlazi iz magacina istovremeno (a meni nije pozanto da postoji takav dokument). Za ovo rešenje sa dve tablice takođe nisam siguran, možda da malo detaljnije obrazložiš šta si pod time mislio. Ako ovo pitaš u vezi sa magacinskim poslovanjem, pa ti treba nekakva robna kartica, onda u istu tabelu ćeš upisivati i jedno i drugo, s tim što izlaz upisuješ sa oznakom minus.

Ako može malo detaljnije objašnjenje, možda bih ti mogao više pomoći.

Pokušavam da dotjeram bazu u koju se sprema poslovanje skladišta, dakle ulazi i izlazi robe u skladište.
Kada roba ulazi u skladište ona može ulaziti sa tri vrste dokumenata.
1. Primka tj. dokument koji se popunjava kada roba dolazi od vanjskog dobavljača
2. Interna predatnica, dokument kada u skladište ulazi roba (poloproizvodi) iz vlastite proizvodnje.
3. Povratnica, dokument kada je roba izašla iz skladišta pa se iz nekog razloga vrača u skladište

Kdada roba izlazi

1. Trebovnica - roba sa skladišta izlazi u proizvodni pogon radi ugradnje u finalni proizvod.
2. Otpremnica kooperacije - roba izlazi na doradu kod vanjskog partnera
3. Otpremnica materijala - roba izlazi jer je prodana vanjskom kupcu.

Ja sam to zamislio da napravim prvo tablicu "DOKUMENTI" koja će imati polje ID dokumenta i naziv dokumenta. Ona bi sadržavala popis svih gore navedenih dokumenata.
Zatim tablicu, koja bi trebala biti jedinstveno zaglavlje za sve ove vrste dokumenata, a uključivala bi ID vrste dokumenta, broj dokumenta, datum i polje ID koje će ovo zaglavlje povezivati sa drugom tablicom u kojoj će biti detalji o robi koja se odnosi na pojedini dokument. U toj drugoj tablici bi bila šifra materijala, jedinica mjere i količina koja je ušla odnosno izašla po tom dokumentu.

Ili bi možda za svaku od gore navedenih dokumenata trabala posebna tablica.

U ovom prvom slučaju (zajednička tablica) bi ti ta tablica automatski predstavljala i robnu karticu. Jedino treba voditi računa o tome da se izlazne količine prefiksuju minusom, što možeš rešiti programski (dakle da ne opterećuješ korisnika da pazi na to). To možda i nije loše rešenje ako svi ti dokumenti uniformno izgledaju, pošto ja sada ne mogu da se setim nijednog drugog razloga protiv osim tog minusa. :) S druge strane, kod situacije sa više tablica ne moraš da brineš o tome da li je količina u plusu ili minusu, ali moraš posle to sve povezivati kada ti treba zbirni pregled. Ovo i nije tako problem (koristi se UNION query), ali može lako da se izbegne na ovaj prvi način.

Ja do sada nisam susretao ovu situaciju, doduše ovo što sam radio je uvek podrazumevalo dovoljno različite ulazne i izlazne dokumente da nije moglo da se modeluje preko jedne tablice.

Evo jednog kopetentnog mišljenja, a odnosi se baš na situaciju koju imamo u formi Kartica sa početka ove teme.

Rebecca M. Riordan , Projektovanje baza podataka, Mikro kniga, 2006
Poglavlje 17 Predstavljanje entiteta na obrascima

Ponekad će te imati obrazac sa primarnom tabelom koja učestvuje u više veza tipa „jedan prema više“, a potrebno je da prikažete više od jedne tabele na strani „više“ tih veza.
Ako prihvatite moj savet, izbegavajte takve situacije kad god možete. Projektovanje prikazivanja većeg broja tabela na strani „više“ na obrascu može biti teško, a njegova izrada još teža, ali ponekad nećete imati drugog izbora. Ako na istom obrascu morate da prikažete veći broj veza tipa „jedan prema više“, najjednostavnije rešenje je da za prikazivanje podataka sa strane „više“ upotrebite grupu kartica. To rešenje obezbeđuje korisnicima jasan kontekst. Osim toga može da poboljša performanse, budući da se zapisi za grupu kartica moraju učitati samo kada se prikazuje sadržaj kartice.
Po svaku cenu treba da izbegnete vidljivu gomilu kontrola koja prikazuje zapise na strani „više“ iz većeg broja veza „jedan prema više“ istovremeno.


Naravno ovo nije direktno rešenje za kontrolu Text61 STANJE REZERVACIJA. Tamo bi eventualno moglo da pomogne pisanje VBA koda na OnCurrent događaj glavne forme, pa ako je izvor podataka u FrmRezervacije prazan sugerisati kontroli Text61 na glavnoj formi ispis jednak nuli. No to već spada u domen "Šta bi bilo kad bi bilo".

Dakle savet je: poslušati ženu koja je između ostalog i nosilac Mikrosoftovog zvanja MVP(Most Valuable Professional).