Da. Možeš da koristiš funkciju Nz() ili IsNull().
U predzadnjem postu kažeš ovako:
“Ako odete na komitenti --> Kupac1 --> Detaljan Pregled Stanja izvestaj ce se otvoriti bez problema. Medjutim ako odete na Kupac2 izbaci ce gresku o kojoj sam vec ranije pisao.
Takodje, ako bi postupno brisali podatke za Kupac1, redom iz pojedinih tabela izvestaj se otvara sve dok se ne obrisu podaci iz poslednje tabele (mislim da red brisanja podatak iz tabela nije bitan, efekat je isti), nakon cega se vise nece otvarati. „
Iz ovog što si napisao sledi da se izveštaj otvara sve dok ima bilo kakav podatak da prikaže. Znači ako nisi pobrisao podatke za Kupac2 iz tabele Krediti uzveštaj radi.
Dalje u zadnjem postu kažeš ovako:
„Od presretanja greske ne bezim, ali je potrebno da se izvestaj otvori i kada imam samo recimo Racun, ili samo IzvozniRacun itd. Slozices se da jedan kupac moze u jednom trenutku imati samo Racun, a da nije pocetno zaduzen i da mu nije odobreno kreditiranje.”
Ova dva citat mi se čini kontradiktorna. Ja nemam mogućnosti da ispitujem i testiram ceo program i prepravljam kod ali ako za Kupac2 (K02) imaš bilo koji podatak, recimo IzvozniRacun i izveštaj se otvara kako ti tvrdiš u prvom citatu, onda je jedino rešenje da kad ne bude podataka zatvoriš prazan prikaz i eventualne greške već pomenutim kodom koji sam ti napisao.
To da si nadograđivao bazu koja je sad kako kažeš konfuzna je posebna priča. Ne znam koliko vredi da da ti savetujem da kreneš od početka. Posao je ogroman ali će buduća muka oko održavanja biti još veća ako nastaviš ovako. Izračunata polja ne opterećuju samu bazu po pitanju brzine već joj daju mogućnost da bude ne-konzistentna. Srpski rečeno nekorektni podaci pre ili posle. Zbog ponavljanja istih podataka i korišćenja izračunatih polja, može se dogoditi da se promena vrednosti primercima istog podatka ne izvede dosledno, tj. da se jednom primerku istog podatka vrednost promeni (namerno ili nenamerno), a da se to ne učini sa ostalim primercima tog podatka ili se ne izvrši izračunavanje. Rezultat možeš da zamisliš. Zbog toga se takve stvari izbegavaju.
I da pojasnim ono oko prve primedbe i separacije (cepanje entiteta na jednostavnije). U delu baze koji si prikazao, a verujem da toga ima još, ti imaš sledeće dokumente: Racun, IzvozniRacun, Izvod i Kredit. U vezi sa tim imaš i sledeće tabele:
Racuni, OpisRacuna, Izvodi, OpisIzvoda, IzvozniRacun, OpisIzvoznogRacuna, Kreditiranje, OpisKreditiranja.
Po meni tri tabele: VrstaDokumenata ---> DokumentZaglavlje ---> DokumentStavke
je mnogo bolja varijanta za ovako kompleksan zadatak kojim se baviš. Doveo si sebe u situaciju da ti je model preširok i da ne možeš da ga obuhvatiš jednim pogledom. Alati za modeliranje imaju lek za to u vidu „Subject Area” ili izdvajanja u posebne poglede ili tematska područja. Access-ov Relationships nema tu mogućnost. Najveći je gubitak svakako u rasipanju sopstvenih resursa i energije.
Kod ovakvog modela jedino bi imao u upitu nad dvema tabelama DokumentZaglavlje i DokumentStavke da postaviš uslov: u polju VrstaDokumenta koji su to dokumenti koji ti trebaju, umesto da praviš akrobacije sa upitima: KreditiK, KreditiPZ, KreditiIR, KreditiR i njihovim spajanjem u Union upit, pa ponovnim pozivanjem u sledećem upitu KreditiProbni.
Tvoj pristup je dobar za neki jednostavan zadatak. Recimo prodaja brze hrane, gde postoje dve vrste dokumenata: Ulazne kalkulacije i izlazni računi (kasa blok).
Problem sa izvestajem KEPU
Re: Problem sa izvestajem KEPU
Re: Problem sa izvestajem KEPU
Re: Problem sa izvestajem KEPU