Aplikacija u access-u, pitanja.

Imam nekoliko pitanja oko Access aplikacije:

1. Da li postoji nacin da textbox-ovi koji se kreiraju prilikom pravljenja forme i referenciraju na neku tabelu ne prikazuju record-e u bazi? Npr. hocu da imam formu za unos novog record-a u tabelu a neprakticno mi je da se tada prikazuju svi record-i pa onda da biram opciju dodaj novi. Opcija za referenciranje mi odgovara samo ako hocu da izlistam proizvode ali i tada dajem korisniku mogucnost da menja podatke bez upozorenja a meni treba malo veca kontrola. Nisam nigde video primer da izaberem opciju dodaj novi record pa mi ponudi prazne kontrole, na opciju izlistaj ponudi mi samo da mogu da ih gledam a na opciju izmeni ponudi mi da menjam ali samo na dugme potvrdi se stvarno izmene reflektuju u tabeli. Da li je jedino resenje da kreiram textbox-ove bez referenciranja na tabelu i command button pa da kroz VBA kod na njegov click dodam record i ostale operacije?

2. Kako se uobicajeno pravi racun? Hocu da pravim racun, izaberem kupca i popune se odgovarajuca polja u formi (to nije problem) a onda da izaberem proizvod, otvori mi se jedan red za njega koji mu prikaze naziv i cenu, upisem mu kolicinu i on ispise punu cenu (ni to nije problem), ali onda hocu sledeci prozivod u novom redu. U nekom smislu, trebalo bi da se dinamicki kreiraju textbox-ovi za nove proizvode i da se to na kraju odstampa. Ili se to pravi u izvestaju?

3. Da li sam pravilno primetio da se u access-u ne moze menjati pozadinska boja command button-a osim postavljanjem slike cime se prilicno ogranicava dizajn?

Toliko za sada.


_{[Ovu poruku je menjao Neznanac_ dana 01.07.2007. u 15:41 GMT+1]}

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]}

---