1. Prilikom otvaranja forme na OnOpen događaj
DoCmd.GoToRecord , , acNewRec (ide na novi slog)
Ako hoćeš da dozvoliš editovanje otvori formu sa DoCmd.OpenForm,,,,acFormEdit ili ako hoćeš samo da dozvoliš pregled onda DoCmd.OpenForm,,,,acFormReadOnly. Kad počneš da kucaš komandu u VBA otvoriće ti se prozorčić sa mogućim opcijama.

2. Textbox-ove pretvori u ComboBoxove i veži za žifarnik proizvoda i odatle biraj proizvode, a stavke računa popunjavaj u podformi koja je Datasheet. U stvari tebi trebaju za Racun dve tabele: Tabela Zaglavlje računa na kojem biraš kupca unosiš datum racuna i slično, Tabela Stavke računa u koju unosiš proizvod, cenu, količinu. Prva tabela je vezana za Single Form, a druga za Datasheet. Forma i podforma su povezane preko Link Chield Fields i Link Master Fields.

3. Ovo stvarno nisam isprobavao. Probam, pa javim.

Da. Zbilja ne može. Imam jednu .mdb sa mnogo raznih dugmića za Access ali su svi sa sličicama (size oko 3 Mb). Ako ti treba javi pa da je spakujem bude oko 215 kB.

Zakačio sam zipovanu datoteku sa sličicama. Uživajte



_{[Ovu poruku je menjao Getsbi dana 01.08.2009. u 15:34 GMT+1]}

1. Hvala na odgovorima. Probacu ove opcije

2. Napravio sam vec ranije 2 tabele koje si pominjao, sve je to kroz bazu dobro odradjeno i povezano samo nigde nisam video primer kako se to resava u formi, tj.kako se popunjava, da je korisniku ugodan rad. Nisam koristio datasheet (posto nikad nisam radio aplikaciju u access-u a u ovom slucaju mi se cini kao dovoljno dobra pa hocu da probam, a ako ne uspem uvek se mogu vratiti drugom progamu) pa cu videti da li mogu da se izborim. Ako neko slucajno ima neki gotov primer, bilo bi super.

3. Moze, super, poslacu ti adresu u pm-u.

Hvala jos jednom, ako naidjem na jos neke nedoumice javljam se.

2. U Northwind-u, forma Orders i Orders subform. To ti je ugledni primer. Nalazi se na Help, Sample Databases, Northwind Sample Databases. Verovatno će da traži da se do-instalira ako već nije instaliran.

1. Možeš si sam kontrolirat upis i ispravak, ako ne želiš da ti podaci budu prikaćeni na formi iz tabele
znaši contrlosource u txt boxovim ti je prazan i kad klikneš na tipku za upis/ispravak imaš kod
ovo je iz mog koda proimjer gdje unašaš ili ispravljaš podatke iz tabele !!

If IsNull(sifrazemlje) Or sifrazemlje = "" Then
MsgBox "Šifra zemljee nije unešena"
sifrazemlje.SetFocus
Exit Sub
End If


Dim d As Database
Dim R As Recordset
Set d = CurrentDb
Set R = d.OpenRecordset("select * from tbldrzave where sifrazemlje='" & sifrazemlje & "'")

If R.EOF Then
R.AddNew 'dodavanje
Else
R.Edit 'mjenjanje
End If
R.Fields("sifrazemlje") = sifrazemlje
R.Fields("naziv") = Nazivzemlje

R.Update
R.Close
Set d = Nothing
subDrzave.Requery
sifrazemlje.SetFocus


Pozdrav

Getsbi, hvala na mail-u.
Ovaj primer u Northwind-u, forma Orders i Orders subform je bas ono sto mi treba, sto cu da primenim kod sebe.
Trtko, mozes li da zakacis konkretan primer sa tabelom i formom da vidim kako ovo radi?
Hvala obojici.

Evo kačim jedan primjer
Napravljen je u Accessu 2002
a ako koristiš 2000 , konvertujem u 2000 pa ti pošaljem

Pozdrav

@ Trtko; Tabela tblDrzave je linkovana. Zakači .mdb sa tabelom.

A zaboravih da je linkovana,
Sad šaljem s tablicom

Hvala obojici. Pomogao mi je ovaj primer pa sam sad shvatio kako se prave subforme i vezuju. Takodje sam upoznao query, pa me zanima da li u njemu moze da se napravi sledeca stvar:
Imam npr. jednu tabelu ciji podaci idu na fakturu. Posto ne zelim da cuvam sve podatke za sve fakture, da ne dobijem redudansu, ja pravim query koji se referencira na ovu tabelu. Medjutim, posto se podaci u toj tabeli menjaju, imam posebnu tabelu u kojoj cuvam istoriju izmena i u njoj mi stoji id atributa kome se menja vrednost, vrednost i datum do kad je vazio. Zelim da kad gledam stare fakture na svakoj bude vrednost atributa kakva je bila u vreme kreiranja fakture. Da li moze preko query-ja da se postavi uslov da se vrednost cita iz tabele istorija ako postoji do tog datuma ili ako ne postoji (znaci da nije bilo izmena ili da je faktura pravljena nakon poslednje izmene atributa) iz polazne tabele?
(ili je resenje da tabela istorije sadrzi atribute startdate i enddate pa da se uvek iz nje cita?)
Trtko, ovaj primer nije ono na sta sam mislio. Zelim da kad obradjujem jednu tabelu, imam na meni formi dugme koje kaze unesi novi npr. artikal, otvori formu za praznim odgovarajucim poljima koje sadrzi tabela artikal (otvorim formu sa opcijom DoCmd.GoToRecord , , acNewRec), ali da se novi slog unese tek kad kliknem na dugme Sacuvaj. Isto tako za izmenu artikla, otvorim formu sa DoCmd.OpenForm,,,,acFormEdit ali izmene se sacuvaju tek kad kliknem na odgovarajuce dugme.
Ne znam da li je to moguce sa textbox-ovima koji su napravljeni preko wizard-a koji automatski vezuje textbox za odgovarajuci atribut.

1. Verovatno da može da se napiše takav query kakav si ti poželeo međutim faktura je dokument koji ne može da do određenog datuma ima ovakve vrednosti, a nadalje druge. To jednostavno nije dozvoljeno zakonom o računovodstvu. Šta znači „da nije bilo izmena ili da je faktura pravljena nakon poslednje izmene atributa“ ? Odgovori mi da bih ti dao pravi savet. Što se tiče redudance trudiš se da je ima što manje. Teško da ćeš napraviti model potpuno bez nje pogotovo kad je kompleksniji projektni zadatak. Nije redudanca čuvati sve podatke za sve fakture nego čuvati ih nepotrebno na dva ili više mesta. Mislim da ćeš morati da sačuvaš svaki podatak za pojedinačnu fakturu na ovaj ili onaj način u tabelama. Query-ju su samo filtriranje tabela ili pogledi na tabele. Voleo bih da vidim model podataka, moguće je da se ranom ispravkom preduprede kasniji problemi.


2. Ako su ti polja na formi “bound ili vezana“ (recimo text box i Control Source mu je vezano za kolonu iz tabele), što je kod tebe slučaj onda se sa zadnjim unesenim poljem na formi automatdki izvršava insert sloga u tabeli. Ako želiš Command buton "Save", možeš da postaviš polja na formi da budu unbound ili nevezana, pa da nakon popunjenog zadnjeg polja na On Click događaj tog dugmeta izvršiš proceduru za unos sloga u taelu. Ovakva forma se ne radi iz Wizard-a ili ako je već urađena moraćeš da je prepraviš. Neophodno je napisati proceduru u VBA za popunjavanje sloga. Bio je primer na forumu oko ažuriranja tabela iz druge tabele. Postupak je sličan.

1. Naravno da necu da menjam nista na fakturi koja je vec izdana! Bas zbog toga sam i postavio ovo pitanje. Ako nisam bio dovoljno jasan onda cu da napisem primer. Na fakturi stoji ime kupca, adresa, PIB itd.. Ako bih stavio da se u tabeli za fakturu pamte svi ovi podaci imao bih redudansu (redundansa je npr. kad imas tabelu Korisnici gde za svakog korisnika unosis dosta slogova dnevno, od toga mu se grad ponavlja i umesto da u toj tabeli koja se stalno azurira imas kolonu grad ti napravis drugu tabelu u kojoj stoji id kupca grad i povezes je sa ovom). Zato ja ove podatke uzimam iz tabele kupci. Medjutim, ako bi kupac promenio adresu a ja vezem fakture na tabelu kupca, onda bih prilikom izlistavanja faktura iz perioda pre promene dobio novu adresu a to nije korektno. Zbog toga imam ovu tabelu promena.

2. To sam i pretpostavio, ali sam hteo da proverim. Znam kako se to radi u VB-u pa cu se snaci kako se to radi u access-u.

Hvala

Ok. Sad je jasnije. Imao sam sasvim drugi dojam kad sam pročitao post. Dakle reč je o promeni vrednosti nekih atributa roditeljske tabele (recimo KUPCI), a ne atributa tabele (recimo FAKTURA) koja je u ovoj vezi dete, a koja po zakonu ne bi smela da se menja. Rešenje sa istorijatom je onda uredu sve dok se ne menjaju atributi naziv ili PIB jer takve izmene povlače i promenu ID kupca, a to onda i jeste drugi kupac. Razmisli o izbacivanju ID kupca i ostavljanju PIB-a kao atrbuta koji će jednoznačno da određuje slogove u tabeli KUPCI koja je šifarnik u ovom slučaju. Cilj zakonodavca je bio da uvođenjem PIB-a napravi jedinstveni šifarnik. Upravo ovo sam i ja uradio pre oko godinu-dve. Ovo je samo savet.

Što se tiče tvog inicijalnog pitanja oko istorijata onda bi umesto direktnog korišćenja tabele KUPCI za pravljenje izveštaja o FAKTURAMA koristio queri KUPCI kao jedan od izvora, a njega bi dobio upravo tako kako si i zamislio ispitivanjem datuma do kog je važilo stanje o atributima tabele KUPCI podložnim izmeni.

Više sam za prvu varijantu ako uspemo da je izvedem nego za startdate i enddate. No sačekajmo još malo, možda neko ima bolju ideju. Ima na ovom forumu još ljudi koji su se time bavili. Možda se javi Zidar. On ima dosta iskustva oko query-ja i pisanja SQL-a.

Posto me Getsbi pozvao, moram da se javim


Dobro si uocio da se non-key podaci o kupcu poenkad menjaju. Promeni se adresa, telefon i slicno. Naravno da ako vuces te podatke iz tabele Kupci, dobices tekuce podatke, sto ce da pokvari prethodno izdate fakture ili druge dokumente. problem je sto ni jedna knjiga ne pise kako se ovo resava. Za skolske prilike, pretpostavi se da se podaci o kupcu nikada nece manjati i dobiju se lepi skolski primeri normalizovanih sistema. I mi svi naravno po skolski modeliramo realne sisteme, i svi naidjemo na isti problem - kako obezbediti da se ne promene sve fakture kad se promeni adresa kupca.

Teorijski, postoje dva nacina da se ovo uradi:
a) U tabeli Fakture uvesti kolone koje pamte bas te informacije - adresa, telefom, ime kupca i naravno nekakav ID kupca. ID kupca (PIB) sluzi da se tabela KUpci poveze sa ostalim tabelama. Ostale kolone, ma kako redundantono izgledalale, imaju ulogu da sacuvaju snapshot podataka o kupcu. U ovoj varijanti bi se podaci o kupcu jednostavno prepisivali iz tabele Kupci (ili skupa tabela koji cuvaju podatke o kupcima) u tabelu Fakture.

b) Da se tabela Kupci vodi dinamicki. Pretpostavka je da se oni podaci o kupcu koji se ispisuju na fakturi cuvaju u tabeli Kupci.. Dodas jednu kolonu, DatumOdKogaVazePodaci (ne dve, nema EndDate). Znaci, od dana tog i tog, vazi jedan skup podataka o kupcu. Cim se promeni bilo sta (adresa, telefon), pravi se novi rekord o kupcu i dodaje u tabelu Kupci, sa novim DatumOdKogaVazePodaci. Kad god se napravi nova faktura, uzimaju se podaci iz poslednjeg rekorda o kupcima. Kad hoces da prikazes fakture iz proslosti, pogledas datum u tabeli Fakture. Onda pronadjes kverijem izmedju koja dva rekorda u tabeli kupci pada datum fakture, pa procitas podatke za manji DatumOdKogaVazePodaci. Postoje razne varijante ovog nacina, ali se svode na isto - pamti vremenski period kada vaze neki podaci.

Prvi nacin naoko je gluplji, jer daje na prvi pogled redundansu - cuva podatke o kupcu na dva mesta. Ovu tvrdnju cemo malo da naliziramo za koji trenutak.

Drugi nacin deluje pametnije, nema redundanse. Ali je mnogo komplikovaniji. Uvodimo vremensku dimenziju u igru, a to nije naivna stvar. I sam si primetio da je problem kako iz tvoje tabele sa promenama izvuces bas onaj rekord koji ti treba. Zahvali datumskim kolonama za to
Dalje, rekosmo 'kreiras novi rekord za kupca'. Sta ce da bude Primary key u takvoj tabeli? KupacID ne moze, jer se ponavlja od rekorda do rekorda. Zanci, treba nam KupacID plus jos nesto drugo. DatumOdKogaVAzePodaci nije los kandidat za postizanje jedinstvenosti, sldi PK (KupacID, DatumOdKogaVazePodaci). Ali onda treba da se menja i tabela Fakture. Ne moze da se veze tabela Fakture samo na KupacID, mora na (KupacID,DatumOdKogaVazePodaci). To je OK, dobili smo direktnu vezu na dinamicku tabelu Kupci. Medjutim, sada imamo problem da odgovorimo na prosto pitanje: prikazi mi podatke u kupcu. Ne moze vise jednostavno SELECT * FROM Kupci WJHERE KupacID = 17. Mora nesto ovako:

SELECT * FROM Kupci AS A
WHERE DatumOdKogaVAzePodaci = (SELECT MAX(DatumOdKogaVAzePodaci ) FROM Kupci AS B WHERE A.JupacID =B.KupacID)
AND A.KupacID = 17

Da li si spreman da stalno mislis o dinamickoj prirodi tabele Kupci i da pises ovakve kverije? Kveri koji sam napisao NE MOZE da se napise u Access Query Designer prozoru, mora da se kuca u SQL prozoru.

A i redundansa je tu, big time. Ako kupac promeni telefon tri puta, imaces tri rekorda sa potpuno istim podacima, osim kolone telefon.
Znaci, menja se model znacajno, se se komplikuje i opet imas redundansu. Umesto u tabeli Fakture, redundansa je u tabeli Kupci.

Da malo razmotrimo tvrdnju da kopiranje adrese i telefona kupca u fakturu predstavlja redundansu. Ta adresa i taj telefon su deo fakture. Ti podaci se prepisuju iz neke tamo tabele, ali su deo fakture. Faktura ne moze da postoji bez podataka o kupcu. Prema tome, ti podaci pripadaju fakturi. Posmatrajmo stvari ovako: 'Adresa kupca' na fakturi, nije 'adresa kupca'. To je 'adresa kupcan fakturi'. Adresa kupca na fakturi se moze i treba definisati kao 'adresa koju je kupac imao u vreme pravljenja fakture'. To je veoma razlicita stvar od 'adresa kupca' u tabelama o kupcu, koja se definise kao 'trenutna adresa kupca'. A sve postaje mnogo jednostavnije ako prihvatis da 'adresa kupca na fakturi' i 'trenutna adresa kupca' generalno nisu ista stvar. Kveriji postaju (ostaju) daleko jednostavniji i ceo sistem nogo razumljiviji. Jedini donekle komplikovan deo je kopiranje zahtevanih podataka o kupcu iz tabela (mnozina, generalno nije iz jedne tabele nego iz nekoliko tabela) o kupcima. Siguran sam da to mozes lakse da uradis nego da lomis vrat sa kverijima i vremenskom dimenzijom.

Zamisli dinamicku varijantu A) kada podaci o kupcima nisu u jednoj tabeli, nego u vise njih..... Ili da cuvas trenutno stanje u tabeli Kupci, istoriju adresau tabeli KupciIstorija. Onda ti treba i UNION..... Igranka bez prestanka. U jednoj knjizi sam nasao zgodan naziv za ovo: 'eksplozija sistema'

Radi kako hoces, mi smo ti kazali sat smo znali i umeli. Ako insistiras da ides sa dinamickom tabelom o kupcima, i treba ti kveri koji ce da pronadje korektan rekord o kupcu na osnovu datuma na fakturi, molim te da zakacis primer sa konkretnim podacima, pa cemo ti pomoci oko kverija. Za sve ostalo - sam si kriv

Zidar, hvala na savetu. Upravo cu tako da uradim, faktura ce mi imati sva polja koja se menjaju kod kupca i necu dodatno komplikovati. Imam novi set pitanja :)

1. Kako se uobicajeno radi pregled, izmena i dodavanje slogova u tabelu u accessu?
Ono sto sam do sada video, da se na formi nalaze bound polja i moze da se ide od sloga do sloga, da se pregledaju, dodaje novi i menja. Ono sto mi se ne dopada u tom resenju je prvo sto pregled nije ustvari pregledan (u jednom trenutku se vidi jedan slog) , a drugo sto prilikom pregleda bilo koja izmena, pa makar i slucajna se bez upozorenja izvrsi! Ista bi bila varijanta kad bi se postavljalo kad je forma samo citljiva, kad moze da se edituju jer i u tom slucaju kad se udje u edit mod bez upozorenja se sve promene cuvaju. Dakle, resenje je sa unbound poljima. Posto u access-u nije podrzan datagrid vec subforma nisam uspeo da napravim neko elegantno resenje, koje bi korisniku bilo prihvatljivo. Da li postoji neki primer, standard kako se to radi, da ne izmisljam toplu vodu?

2. Kako se u access-u vrsi ispitivanje tipa podataka? Neprihvatljivo mi je da kad dodje do unosa pogresne vrednosti access podize svoj msgbox. Da li se to radi kroz VBA, opcijama tipa IsNumber, Is...?

Ovo sve imaš lepo dokumentovano u Northwind aplikaciji, a i detaljno je objašnjeno u helpu. Sve što si naveo Access podržava i uopšte nije komplikovano da se izvede.

Za prvu stvar, koristićeš svakako bound polja. Ako je problem "automatsko" čuvanje podataka, onda ćeš pisati VBA kôd u formin AfterUpdate event i proveravati Me.Dirty. Druga mogućnost je da formu proglasiš kao read-only, a onda napraviš dugme kojim se forma "otključava" za editovanje. A što se same preglednosti tiče, koristi tabelarni prikaz podataka (Datasheet View) za prikaz više slogova odjednom, a Form View za prikaz detalja pojedinog sloga.

Video sam i rešenje gde je glavna forma podeljena na dva dela, pa u gornjoj polovini imaš Datasheet View, a u donjoj kontrole za izmenu trenutno selektovanog sloga. To je ok gde imaš česte izmene, ali bespotrebno zauzimaš prostor na ekranu i to prikazujući dva puta iste podatke. Ja idem na varijantu duplog klika na neki slog (ili neka kombinacija tastera) koja mi otvara edit formu.

Što se drugog pitanja tiče, dovoljno je da podesiš odgovarajući Data Type u tabeli, Validation rule i Validation Error. Ako te ni ovo ne zadovoljava, postaviš OnError event za formu i tu hvataš greške pri validaciji. Ne znam tačno koji su brojevi grešaka u pitanju, to ćeš naći u Helpu. Kada se dogodi ta greška, samo prikaži svoj Message Box ili već šta koristiš.

Hvala lukeguy, pogledacu sta si napisao, samo ne znam u kojoj je to formi u Nortwind aplikaciji podrzano.
U medjuvremenu sam dosao do jednog elegantnog resenje za 1:

Radim sa unbound poljima, unos ide standardno, pregled radim preko sub forme u kojoj nije dozvoljeno brisanje i editovanje. Na command button izmeni uzmem prvo polje selektovanog sloga u subreport-u (koje mi je i primarni kljuc) i na osnovu njegove vrednosti citam iz baze ostala polja i unosim ih u tekstualna polja. To citanje prvog sloga radim preko opcije ImeSubForme.Controls.Item(0) pa ne znam da li je to dobar metod?

@Neznanac_: Lepo napredujes A i dobra ekipa te savetuje.

Ideja da se sve odradi na formi koja je unbound nije losa i neke dobre knjige o Accessu je veoma preporucuju. S jednom ogradom: radi samo akd unosis tacno jedan slog u neku tabelu. Prosto, napravis unbound formu, stavis polja koja ti trebaju, uneses vrednosti i onda korisnik treba da pritisne dugme "Save" da bi sve otislo tabelu. E, to "Save" je veoma kompleksna stvar. Tu se vrsi validacija. Koja polja nedostaju, koja imaju nepravilne vrednosti, medjusobni odnos pojedinih polja i slicno. Znaci, cmdSave bi pozivalo neku validacionu funkciju kojoj bio poslali polja od interesa kao parametre.Onda bi se aktivirala funkcija koja izracunava ili pravi PK, ukoliko PK nije autonumber. Tu je mali problem u visekorisnickomradu. kako napraviti PK da ska stanica moze u svakom momentu da generise jedinstveni PK. O tom enecemo sada, ali ti to moras da resis. Ako ti je PK neki autonumber, naoko je lakse, o tome brine Access. jedino sto ti u momentu snimanja rekorda ne znas koji ce ti biti PK, pa ti treba kod da ti kaze koji je to PK Access dodelio ovo rekordu koji si upravo snimio. Ovo sve podrazumeva manipulaciju rekorsetima, ADO ili DAO, svejedno. Za nekoga ko dolazi iz VB to je prirodan nacin rada.

Medjutim, ako ti treba unos neceka kao sto je Faktura, ond se bavis sa dve tabele u istom omentu. Tada gore opisani nacin nije vise praktican, mnogo se komplikuje. Ono sto se radi jeste Forma-<Subforma kombinacija. Tabele Faktura i StavkeFakture su u vezi jedna faktura vise stavki (mora biti bar jedna stavka). Lukeguy je preporucio ono sto ja radim za slucajeve Faktura-Stavke. DA krenemo od pocetka.

Imas datasheet (moze i continious form = zgleda kao datasheet), koji je read only i prikazuje postojece fakture (bez detalja). Za pregled ili editovanje postojece uradis kao sto rece Lukeguy: double click na neko polje u datasheetu (cont. formi), obicno PK polje, ostvarads master formu u read only rezimu. mAster forma pokazuje relevantne podatke iz tabele Fakture a subforma na master formi prikazuje stavke. Naravno da je subforma bound, to jest povezana sa master formom. Uoci kako su master forma i subforma u relaciji 1: vise, bas kao i tabele fakture i Stavkefakture. Znaci, relaciju izmedju tabela preslikas u fromu sa subformom. Negde u form header sekciji datasheeta stavis tri dugmeta: cmdView, cmdEdit i cmdAddNew. sve tri pozivaju master formu, ali na malo drugaciji nacin. Kod iz a dugmadi izgleda otprilike ovako:



Da bi ovo lepo radilo, pozeljno je eliminisati Accessove navigation buttons i jos ponesto, pa setujte za master formu:
properties.format.navigation buttons = no (ne zelite da vas zbunjuju Accessovi dugmici, jer se tako moze kreirati i novi rekord, a vi zelite potpunu kontrolu)
properties.Other.Cycle = current record (ne zelite da posle poslednjeg polja odete na 'sledec' rekord jer on ne postoji u slucaju readOnly i Edit, zbog Where condition)

dakle, ideja je ovao:

1) datsheet (contin.) forma kontrolise kretanje kroz tabelu sa fakturama. Kretanje i samo kretanje, ne i edit/deleet/add za fakture, pa i tu treba taviti da je cela forma ili datsheet read only

2) ako zelite da menjate ili gledate detalje za neku odredjenu fakturu, nekako je pronadjite (Sort, filter, Right Click Filter By) i onda kliknite cmdView ili cmdEdit. Otvorice vam se tacno taj rekord (faktura) u tacno zelejnom rezimu. Necete moci da doadjete nove rekorde niti da vidite neke druge, znaci na neki nacin ostajete zakljucani u tom rekordu. zato smo menajli one properties.

3) ako zelite da dodate novu fakturu, kliknete cmdDodajNovi i otvorice se ista master forma, ali prazna i ocekivace da unesete podatke. PK ce se automatski preneti u child tabelu, tako subforme rade. U stvari, PK ne mora ni da se vidi na subformi, ne mora cak da bude na subformi ako kontrola uopste, ali to blesavo izgleda. Stavite na subformu sva polja potrebna za povezivanje sa glavnom formom, pa ih ond aucinite nevidljivim. Korisnik ne treba da ih vidi na subformi, od njih nema nikakvu vajdu.
Posto smo ukinuli Access navigation buttons, ne moze se lako dodati jos neki novi rekord posto smo uneli jedan. Znaci, ako iam da se unese vise od jedne fakture, za sada je to moguce ovako: Klikni cmdDodajNovi, unsei fakturu i stavke, zatvori formu, klinki ponovo cmdDodajNovi i sve u krug. Za mnoge slucajeve ovo je dovoljno.

Ako ocekujemo da se unese 50 faktura jedna z adrugom, ne treba nam korak vracanja na datsheet pa ponovo klik na cmdDodajNovi. Dobro bi nam doslo dugme na samoj formi, za dodavanje jos faktura. Ali nam to dugme smeta kad otvorimo formu u ReadOnly ili Edit rezimu. Barem dva resenja su moguca:
1. napravite formu specijalno za unos, kao kopju forme za view/edit, plus dugme. Nije lose ukoliko ste sigurni da ce forma ostati stabilna na duze vreme. Ako dodate novo polje ili promenite logo, moracete da odrzavata dve forme.

2. U komandi Docmd.OpenForm upotrebite OpenArgs parametar. Imali bi nesto kao:



Sada vam treba da form zna koji ste openargs poslali i da reaguje na odgovarajuci nacin. Mozete da na FormOpen event master forme stavite nesto kao:


Uocite kako se DoCmd promenilo. DoCmd sa pocetka je govorilo Accessu u kom rezimu da otvori master formu. DoCmd na master formi govori Accessu sta da uradi - da doda novei rekord (da 'ide' na novi rekord)

U formOpen mozete da radite i druge stvari, ako ste poslali OpenArgs. Mzete na primer da promenite form.Caption tako da napisete "Faktura broj 123456, EDIT" ili "fakture 12345 READ ONLY" ili "Fakture - Doavanje Novih Faktura"

Ostavljam ti da sam pokusas da resis ovo sa Form.Caption.

Eto, svi saveti sus e skupili u jedan. I savet od Lukeguy (datasheet za pretragu plus dugmad za otvaranje master forme) i ono sto je Gatsbi rekao "Docmd.gortOrecord...". A ima i programiranja. Znaci, za svakog ponesto.

I na kraju, ako ne postoji validacija an nivou tabela, treba upotrebiti Form BeforeUpdate event da se sve proveri (da li su prisutni svi podaci koji se traze, da li je njihov medjusobni odnos korektan, da li su vrednosti u dozvoljenim granicama i sve ostalo sta vam treba) dobra je ideja da sto vise data validation bude na nivou tabela. isto tako, before update je dobra ideja u svakom slucaju, jer ponekad poruke o narusavanju validacionih pravila na nivou tabela nisu bas jasne prosecnom korisniku. A mozete da koristite i Form_Error event, ako sto smo pre neki dan opisali.

Ovo je tacno :) i hvala vam svima na pomoci. Dobro si uocio da dolazim iz VB okruzenja i access ucim jer sam cuo da je dobro resenje za ono sto zelim da napravim. Medjutim, kako se programu zbog nedostatka vremena vracam svako mesec dana desava se da se nekih stvari jedva secam kako sam odradio pa cesto razmisljam da ne radim u access-u. A onda vidim neku njegovu mogucnost (za to ste vi krivci :) ) plus moj istrazivacki duh i necu da odustanem.
Imam nekoliko nedoumica kako se to u access-u uobicajeno radi (najvise se odnose na to kad je pozeljno da se query koristi) pa cu ih formulisati u vidu pitanja.
Ako imam racun kome se u zaglavlju nalaze podaci o kupcu a u subformi stavke racuna sa podacima o artiklima. Zelim da u formi popunim sifru racuna, izaberem kupca po nazivu (pri tome bi dobro bilo da access ima mogucnost da se upisivanjem pocetnih slova izbor u combobox-u ogranici na ta slova) i na osnovu njega popunim ostale podatke o kupcu. Zatim izaberem artikal i popune se odgovarajuci podaci o artiklima, plus se upisivanje kolicine na osnovu cene izracunaju svi potrebni iznosi na nivou artikla.
1. Da li se ta forma pravi tako sto izaberem tabele racunZaglavlje i RacunStavke, pa se onda na combobox koji je naziv kupca postavi na dogadjaj afterupdate f-ja koja procita odgovarajuca polja iz tabele kupci na osnovu tog naziva (jedinstven je naravno) i analogno za artikle plus se na polje cena takodje na dogadjaj AfterUpdate postavi odgovarajuca f-ja (f-je mi nije problem da napisem tako da nemojte oko toga da se mucite)? Ili se pravi query na osnovu tih tabela pa ce on sam automatski da za izabrani naziv popuni odgovarajuca polja? (Ovo mi je uspelo kod subforme ali ne i u glavnoj formi). Ili se query pravi samo za izracunavanja, u ovom slucaju da se izracuna ukupna cena?
Mogu da napravim prvo resenje ali me ipak kopka da li je ovo preporuceno ovako da se radi u access-u?

2. Kako da sprecim da se na istom racunu pojavljuje 1 proizvod jednom (a da ne stavim da mi je primarni kljuc racunaStavke sastavljen i iz id-a proizvoda?)

3. Da li se jedino kroz kod moze podesiti da u subformi stavke pocinju od broja 1 pa na dalje (na svakom racunu) (prim.kljuc za RacunStavke je sifraracuna + rednibrojstavke).

Ovde se zaustavljam za sad jer je i ovako dovoljno pitanja.

>Zelim da u formi popunim sifru racuna, izaberem kupca po nazivu (pri tome bi dobro bilo da access ima mogucnost da se upisivanjem pocetnih slova izbor u combobox-u ogranici na ta slova) i na osnovu njega popunim ostale podatke o kupcu. Zatim izaberem artikal i popune se odgovarajuci podaci o artiklima, plus se upisivanje kolicine na osnovu cene izracunaju svi potrebni iznosi na nivou artikla.<

Combo box radi upravo tako. Dok kucaš slovo po slovo on se pomera i vršiš odabir kupca. Međutim ako shvatiš da je to novi kupac te ga nema na spisku imaš dve alternative.
1. Da privremeo prekineš unos računa, ašuriraš tabelu kupaca, refrešuješ Combo box za kupce i nastaviš unos tamo gde si stao.
2. Da unseš fiktivnog kupca sa šifrom 99999 ili nazivom ZZZZZ dok ne završiš unos računa, a potom se vratiš i ažuriraš tabelu kupaca.
Obe ealternative su izvodljive, a korisnik će ti biti zahvalan ako mu obe i omogućiš.

Što se tiče defaultnog popunjavanja podataka na osnovu šifre artikla to je svakako moguće i o tome je više puta bilo reči na ovom forumu.

> 2. Kako da sprecim da se na istom racunu pojavljuje 1 proizvod jednom (a da ne stavim da mi je primarni kljuc racunaStavke sastavljen i iz id-a proizvoda?) <

Svaki put prilikom unosa novog artikla upotrebiti DLookup funkciju za pretragu po šifri računa i u okviru nje po šifri proizvoda. Mada je složeni ključ elegantnije rešenje i Access kasnije brine o tome, javljajući porukom da je nemoguć upis. Ove poruke se mogu presresti i prevesti na jezik korisnika.

> 3. Da li se jedino kroz kod moze podesiti da u subformi stavke pocinju od broja 1 pa na dalje (na svakom racunu) (prim.kljuc za RacunStavke je sifraracuna + rednibrojstavke). <


Može. U propertiesu kontrole na Defolt Value postaviti nešto slično ovome :
=Nz(DMax("[BrojRacuna]";"Racuni");0)+1


_{[Ovu poruku je menjao Getsbi dana 28.10.2007. u 22:43 GMT+1]}

Hvala na odgovoru.
Mnogo bi mi znacio odgovor na pitanje kako se po standardu prave forme racuna, naveo sam 2 mogucnosti pa me zanima kojim putem da idem.

U data setu koji je record source za formu frmRacunZaglavlje, imas polje KupacID. Postavi dva combo boxa na formu, cboKupacID i cboImeKupca. Oba neka imaju data source jednak KupacID.
U cboKupacID stavi record source samo "SELECT KupacID FROM KUpci".
U cboImeKupca, stavi row source "SELECT KupacID, ImeKupca FROM Kupci", Column Count=2, Column Widths: 0,3cm => nece ti se videti KupacID, nego nazivKupca, a kontrola ce u stvari da ima vrednost KupacID.
Kad promenis vrednost jednog kombo boxa, promenice ti se i drugi. Izaberes kupca po imenu => oba kombo boxa imace vrednost KupacID, cboKupacID ce prikazati KupacID, a cboImeKupca ce prikazati ime.

Kako da prikazes/kopiras relevantne vrednosti za kupca iz tabele tblKupci u tabelu tblZaglavljeRAcuna? Imas dve opcije, moze jedan ili druga, a mogu i obe odjednom (najbolje)

Prvi korak: treba ti after update za cboKupacID i cboImeKupca. Kod u oba eventa je isti - dodeljuje drugim kontrolama na formi vrednost iz tabele tblKupci. Ja najcesce koristim Dlookup, na primer
txtAdresa = Dlookup("Adresa","tblKupci","KUpacID=" & form!cboKupacID)
txtTelefon = Dlookup("Telefon","tblKupci","KUpacID=" & form!cboKupacID)
itd.

NA velikim tabelama Dlookup moze biti spor, pa ako ima desetak Dlookup-a, cela forma postaje spora. Onda mozes da otvoris rekordset koji ce ti vratiti sve trazene vrednosti u jednom cugu. Na primer

DIM db as DAO.Database
DIM rs AS DAO.recordset
SET db = currentdb
Set rs = db.openrecordset("SELECT Adresa, telefon, FROM tblKupci WHERE KupacID = " & me!cboKupacID
rs.movefirst
txtAdresa = rs!Adresa
txtTeleforn = rs!Telefon
itd...

Znaci, kad god izaberes kupca, sva relevantna polja na formi se odmah popune. Pozeljno je da ta polja budy read-only (Locked = Yes)

Drugi Korak: Treba ti i kod na Form Before_Update, da proveri da li se sve ovo desilo, pa ako nije, da pokusa da ponovi operaciju ili bar da spreci cuvanje rekorda.
Ako koristis bound formu subformu, ne treba ti nikakvo dugme za snimanje rekorda na glavnoj formi. Kad sa glavne forme predjes na subformu, rekord na glavnoj formi ce se automatski sacuvati. Novajlije to vole, jedna stvar manje da brinu. neki profesionalci vole da imaju vise kontrole nad snimanjem rekorda, pa zato bar na frominom Before Update izvrse sve potrebne konrole.

Drugi nacin je da nemas nista na After Update za kombo boxove, vec da sve uradis na forminom BeforeUpdate, sto se ne preporucuje. ako vec radis za nekog kupca, lepo je da vidis sta si izabrao.

Sto se tice dodavanja nepostojeceg kupca/dobavljaca u letu i to je veoma popularno, ali se meni ne svidja. Unos kupca u bazu podataka je suvise ozbiljna stvar da bi se tek tako na brzinu odradio dok ti stoji otvoren combo box na tamo nekoj formi. Ako kupac/dobavljac ne postoji u bazi, ostavi racun na stranu, ili zatvori formu. Unesi kupca kako treba (ima li neka interna kontrola, da li je kupac dobro unesen, da li se taj kupac/dobavljac mozda nalazi vec u tabeli pod pogresnim imenom i slicno) pa se vrati i razresi doticni racun.

Access je amlo fleksibilniji i aljkaviji nego VB kad se radi o unosu podataka (autmatsko snimanje bez pitanja i slicne stvari) Zato se puno paznje treba pokloniti back endu, jer Access aplikacija ne moze da ti cuva integritet podataka na nacin an koji to mozda moze VB. Zato je brzina nevidjena. Da dobijes aplikaciju koja izgleda kao da radi, to je ocas posla. D.da je utegnes (citaj: sprecis kojekakve Accessove automatizme i aljkavost) treba pet puta vise vremena. Otprilike, 20% vremena da napravis aplikaciju kojaje 80% kompletna i pouzdana. 80% vremena da je doteras do 100% kompletnosti i pouzdanosti.

Probao sam da primenim savete ali mi neke stvari ne idu bas najbolje. Sad sam na brzinu napravio neku bazu koja moze da prikaze sta zelim da radim sa racunom. Nadam se da u brzini nisam napravio neku znacajnu gresku (vec vidim da mi se na racunu pojavljuje umesto naziva PIB klijenta ali to u realnom modelu nije tako pa zanemarite).
Dakle, zelim da izborom klijenta popunim odgovarajuca polja na racunu (to radim kodom na event before update). Sva ta polja (osim PDVBroj) se upisuju u tabelu racuna zbog eventualnih kasnijih izmena. PDVBroj nema potrebe da se pamti jer ne moze da bude menjan, ali zelim da se uvek vidi na racunu.
Valuta je nesto sto moze i na racunu da se menja i u zavisnosti od nje menja se drugi datum i to je (valjda) korektno odradjeno. Rabat takodje moze da se menja i u zavisnoti od njega treba da se menja vrednost u polju text22, sa predznakom “-“ i tu prijavljuje gresku, kao i na iznosima i izracunavanjima. Kod rabata bih zeleo da stoji i procenat, medjutim kad stavim da je text box tipa percent on rabat iz tabele pomnozi sa 100. Polje NekoIzracunavanje je neka vrednost koja se racuna po formuli koja u buducnosti moze da se izmeni i zato treba da se cuva na nivou racuna a ne stavke i u subformi ne treba da bude vidljivo (sluzi samo za izracunavanje).
Takodje mi treba Getsbi-jevo resenje da stavke racuna na svakom racunu pocinju od 1 pa na dalje na ovom konkretnom primeru.
I na kraju, trebalo bi iz ovog racuna generisati izvestaj koji ce se stampati.
Unapred (a i unazad za sve prethodno) zahvalan.

Mislim da fali jos jedna tabela gde bih odvojio adresu jer jedan kupac moze imati vise maloprodajnih objekata i isti pib i tekuce racune samo je mesto isporuke drugo.

@ Neznanac
Pošto si me prozvao za rešenje da se stavke povećavaju za jedan u okviru broja računa moram da opravdam tvrdnju. U tvom slučaju rešenje bi izgledalo ovako:

Polje BrStavke zaključaj stavivši osobinu Locked na Yes. U događaj podforme Before Update

Postavi kod:
Me![BrStavke] = Nz(DMax("[BrStavke]", "StavkeRacuna", "[BrojRacuna]=FORM.[BrojRacuna]"), 0)+ 1

Sve drugo u na brzinu napravljenom primeru ne mogu da ispravljam, a razloge ću izneti u daljem tekstu. Dakle da krenem redom od tabela. Savkov je u pravu što se tiče kupaca. Oni mogu imati više objekata i roba ide na adresu objekta. Da li račun ide na adresu objekta ili na adresu sedišta firme je diskutabilno. Pre bih rekao da robu prati otpremnica i da kupac na osnovu nje radi kalkulaciju za svaki objekat, a da račun može stići i naknadno ali na adresu sedišta kupca. Međutim i da usvojimo do kraja tvrdnju Savkova ne preporučujem ti da komplikuješ model u ovom trenutku dodatnom tabelom bar dok ga ne dovedeš u red. Moguće je da imaš i širi model, a nama si ovde prezentovao neki na brzinu urađeni sa toliko grešaka u formama i sa očekivanjem da to ispravimo posle onako iscrpnih odgovora još od letos na tvoja pitanja.

Zato ću se ovog puta zadržati samo na modelu podataka.

1. Rabat je deo svake stavke i tu kolonu treba premestiti iz zaglavlja u stavke jer se može davati različiti rabat za različitu robu i naručenu količinu.
2. Kolone Adresa i NazivKlijenta treba izbaciti iz tabele zaglavlja jer je u pitanju redudanca podataka. Imaš ih već u tabeli Klijent. Dovoljan je prenešeni ključ PIB, a na formi se mogu videti podaci koji ne moraju biti upisivani u tabelu. Ovi podaci su ti potrebni tek kod štampanja dokumenta.
3. Polje NekoIzračunavanje ne bih da komentarišem.

4. Održavanje rabata u tabeli Klijent je takođe diskutabilno iz tvrdnji koje sam napisao u tački 1.
5. Valuta u tabeli Klijent je takođe nepotrebna po momo mišljenju jer te ona obavezuje da ti kupac ili uvek ima istu valutu (20 dana od isporuke) ili ćeš morati da praviš tabelu istorijata. Nevidim kako ćeš da naknadno odštampaš ispravno račun br. 3 sa valutom od 20 dana ako si je u međuvremenu promenio valutu na 15 dana pri izradi računa br. 8. To je promenljiva kategorija po meni i treba da ostane samo u zaglavlju dokumenta jer je njegov deo i daje se za svaki račun.
6. U tabeli StavkeRacuna nema potrebe držati NazivProizvoda jer ga već ima u roditeljskoj tabeli Proizvod. Dovoljan je preneseni ključ ProizvodID. Ovo je takođe redundabca (suvišnost) podataka.


Savetujem ti da kreneš od ovih primedbi, prepraviš model i da probleme pri izradi formi izlažeš jedan po jedan, kako nailaziš na njih, a ne nagomilano. Uzgred polja koja si postavio na glavnoj formi, a za Control Source imaju vrednosti sa podforme ne mogu da se prikazjuju kontinualno ili sam ja loše shvatio ideju. U svakom slučaju polja u Futeru podforme su nepotrebna. Treba upotrebljavati referenciranje i funkciju Sum() da bi se video ukupan izos svih stavki sa podforme na glavnoj formi.






_{[Ovu poruku je menjao Getsbi dana 17.11.2007. u 09:19 GMT+1]}

Getsbi, nisam te prozvao, samo nisam umeo da implementiram resenje koje si mi ponudio jer sam negde gresio. Sad kad si video konkretan primer i napisao kod on radi! Hvala.
Sto se tice modela, on je pravljen po zahtevu ma kako neuobicajen bio pa evo i objasnjenja po stavkama:

1. Na racunu i na otpremnici treba da stoji adresa sedista kupca, bez obzira na koji maloprodajni objekat se upucuje pa zato nema potrebe za posebnom tabelom.
2. Rabat moze da postoji iskljucivo na nivou racuna a ne moze se desiti da na jednom racunu bude vise razlicitih rabata za razlicite proizvode.
3. O redudansi i istoriji smo pricali na pocetku, pa posto adresa i naziv klijenta mogu da se promene a potrebno je da na racunu uvek bude adresa i naziv koji je bio kad je izdavan ne moze da se veze za tabelu kupca.
4. NekoIzracunavanje je navedeno kao primer jer ce biti izracunavanja koja ce zavisiti od cene i koje kao takvo treba da se pojavi na racunu.
5. Valuta u tabeli kupac treba da postoji jer kupac ima fiksnu valutu, koju dobije kad se unosi u bazu (da se ne bi pamtila, jer je to stvar dogovora prodavca i kupca). Ta valuta se prenosi na racun i samo u pojedinacnim slucajevima se menja (kad kupac kupuje vise/manje robe) i zato treba da se cuva i u tabeli racun i kad stampam racun br.3 procitacu valutu koja je upisana u tabeli racun a ne kupac a isto vazi i za racun br.8.
6. Isto sto vazi za valutu, vazi i za rabat (kupac ima fiskni rabat koji se u pojedinacnom slucaju menja).

Kad je u pitanju suma sa podforme na formi na forumu sam naisao na primer da je prvo sumirano u footer-u subforme pa preneseno na glavnu formu, meni je to cak jednom proradilo ali posle toga javlja gresku.

Ovde sam probleme postavljao pojedinacno i dobijao detaljna uputstva ali nekada nisu resavala problem jer verovatno nisam dobro postavljao pitanje. Zato sam i poslao primer, da lakse uocite kakve probleme imam sa formom racun posto deluje da fale neki detalji koje mogu samo iskusni access programeri da primete.

Evo zakačio sam ispravljen primer. Morao sam da ga preradim jer mi nešto sa fajlom nije bilo u redu. Importovao sam tabele u prazan .mdb i ispoštovao sva tvoja poslovna pravila. Ono za adresu sedišta kupca sam i ja tvrdio opovrgavajući potrebu za dodatnom tabelom. Sa načinom vođenja rabata se ne slažem, ali bože moj. Da bi sračunao rabat za račun, ceo račun mora da bude gotov. Moglo bi na neko dugme na formi, nakon završetka unosa podataka, ali je najbolje da se taj podatak sračuna na iveštaju uz iznos za uplatu. Znači svega manje rabat jednako svega za uplatu. Naravno ostaje da se i porez ukalkuliše ukoliko je potrebno.



_{[Ovu poruku je menjao Getsbi dana 20.11.2007. u 13:52 GMT+1]}

Getsbi, hvala sto si se potrudio oko primera, da shvatis pre svega model pa sad mogu da postavljam, nadam se jasnije pitanja.
Koliko vidim, ti si u ovom primeru uradio sledece:
1. Postavio si kod tako da se redni broj stavke generise automatski i ide od 1 pa na vise kako sam i trazio i kako si mi vec objasnjavao.
2. Postavio si da je i PIB polje combobox, pa se moze i po njemu birati kupac sto je odlicno. Da li si to uradio nakon wizarda, promenivsi textbox u combobox?
3. Izracunao si uspesno ukupno sumu svih proizvoda.
Medjutim, sad se u podformi ne pojavljuje suma na nivou proizvoda i na izbor ProizvodID se ne popunjavaju ostala polja kao u prvobitnom primeru. Posto sam ovo vec radio, nije mi problem da dodam.

Takodje, ne dozvoljava mi da kreiram 2 racuna sa istim kupcem a razlicitim brojem racuna koji je primarni kljuc racuna??
Moja ideja za rabat je bila da posto on zavisi od ukupne sume, da kako se ona menja izborom svakog sledeceg proizvoda i kolicine tako se i rabat menja jer zavisi od nje.
Ono sto nije reseno je:
1. Kad kreiram racun i izaberem kupca on korektno popuni PDVBroj. Ali kad predjem na sledeci racun on u tom polju drzi PDVBroj prethodnog, na izbor kupca postavi odgovarajuci, ali povratkom na prethodni racun on cuva PDVBroj poslednje izabranog kupca
2. Kako da popunim polje NekoIzracunavanje, koje moze biti neki dodatni porez npr. i izracunava se po odredjenoj formuli u zavisnosti od cene i koje mi je potrebno da se vidi na nivou racuna a predstavlja sumu na nivou proizvoda (ali ne smije da bude vidljivo na nivou podforme)? Sta ako se ta formula vremenom menja, da li mora da se ulazi opet u kod?
3. Kako se iz ovog racuna pravi izvestaj, da li se pravi query?

Combo Box za PIB sam napravio ručno, mada nisam siguran da je pametno jer iovako koristim tvoj kod ispod događaja “NazivKlijenta_BeforeUpdate“, što si verovatno primetio. Nisam stigao sve da dodam kako je bilo. Probaj sam. Vodi računa kod pisanja jer neispravna imena kontrola i referenci su najčešći uzročnik greške tipa: # Error kao rezultata u polju.

Što se tiče ključa. Pokidaj vezu u RelationSheeps, obriši podatke u tabelama zaglavlja i staveki, promeni BrojRacuna u LongInteger u obe tabele kao i Broj Stavke takođe u LongInteger u tabeli stavki. Tad ponovo uspostavi vezi. Nisam imao vremena da unosim podatke pa otuda i ne valja.
Loša varijanta je da kombinacija ključa bude razlišitih tipova. Ako ti baš treba neki broj računa tekstualnog tipa bolje je da dodaš posebno polje i nazoveš ga recimo InterniBroj ili tako nekako, a da ne bude deo ključa.

Ostatak ću da pogledam sutra.

Nije ni ovo pomoglo sa promenom tipa podatka u ključu. Sutra ću pogledati.
Proradilo je. Pošto sam iskopirao tvoje tabele, preneo sam i redosled indeksa koji je pogrešno postavljen, tako da je to smetalo. U svakom slučaju bolje je da PK budu Numerici, a da ti dodaš neki interni broj ako je to potrebno.

Evo zakačio sam. Odgovori mi u vezi Primarnog ključa i tipa podatka za Broj računa.






_{[Ovu poruku je menjao Getsbi dana 20.11.2007. u 23:02 GMT+1]}

Otkud ovo: $#.##0,00;($#.##0,00) u Format polja u tabelama i formama, kad postoji limitirana lista : General, Currency, Fixed, Standard,.........
Prepravio sam malo tipove podataka i formate.
Dao sam ti primere za nekoliko sumiranja i prenošenja sa podforme na formu.
Pogledaj šta se piše u Control Source kontrole koje sumiraju u podformi i one koje prezentuju sumirano na glavnoj formi.
Pitanje : “ Sta ako se ta formula vremenom menja, da li mora da se ulazi opet u kod?”
Ako je formula u kodu mora se ispraviti kod. Ako je formula na kontroli mora se ispraviti Control Source kontrole.
Ne vidim razlog da se petljaš sa PDVbroj na frmi. Kad budeš štampao izveštaj automatski ćeš povući i PDVbroj iz tabele Klijent. Ovo nema raloga da se vidi na formi za unos i ažuriranje. Ako baš mora napravićemo i to.
Pitanje “ Kako se iz ovog racuna pravi izvestaj, da li se pravi query?”
Da. Prvo napravi query sa svim potrebnim tabelama, a onda query uzmi za Record Source izveštaja.

Getsbi, hvala ti na pomoci, sto si se potrudio da razumes logiku mog programa i da ga korigujes.
Uspeo sam da uradim ono sto sam zeleo, kombinujuci tvoje i Zidareve savete.
Hvala Zidaru na iscrpnim odgovorima kao i svima koji su se ukljucili u temu. Sjajni ste.