Skrivanje subforme u zavisnosti od vrednosti polja u glavnoj formi

Prvo da napomenem da koristim program Faktura koji je postavio korisnik FOX028. U formi Faktura, ako se prvo počnu unositi artikli u subformi, javlja da nije unesen IDFaktura. Ja sam hteo da mi je subforma nevidljiva dok se ne unese IDFaktura. To sam uradio sledećim kodom

Ovim sam uspeo da sakrijem subformu, ali ona se prikazuje tek kad refresh-ujem formu, s tim da posle refresh-a me vraća na prvu fakturu. Da bi me vratilo na trenutnu fakturu koristio sam kod

Ovo radi ono što mi treba al mi iskreno smeta "treptanje" prilikom Requery-ja. Isto se dešava i ako umesto Visible probam sa Locked. Ima li neko elegantnije rešenje?

Ti očigledno znaš ali da objasnimo i drugima. Me.Refresh osvežava sadržaj tekućeg zapisa, a Me.Requery ponovo učitava celu formu. Probaj da prođeš što jeftinije i ovo drugo upotrebljavaj samo kad moraš. Uz to, isprobaj kako ti program radi na nekoj jačoj mašini. Kod mene recimo nema takvih efekata na 64 bitnoj mašini sa procesorom 3,3 MHz i 8 GB Rama.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Trenutno nemam gde isprobati na boljoj mašini, al ok ako ne može drugačije. Hteo sam malo promeniti, tj. da mi ne proverava za BrojFakture već za IDFaktura koji je autonumber. Ovo iz razloga jer ako želim promeniti BrojFakture pa ga izbrišem subforma mi se vidi pa nevidi itd.. To sam uspeo sa

Problem nastaje sa Requery-jem. Sa kodom

ništa se ne dešava.
Jedino ako se vratim jednu fakturu nazad pa se vratim na trenutnu onda prikazuje subform-u. Kako da osvežim formu kada se promeni IDFaktura koji je autonumber? I da li se to uopšte ovako radi, mislim na postupak kako "naterati" korisnika da prvo unese BrojFakture(IDFaktura) pa tek onda artikle?

Gebneralno nisam imao problema sa osvežavanjem zapisa i ponovnim učitavanjem formi ni na slabijim mašinama. Bar ne takvih da su iritirale korisnika. Odgovoriću samo na zadnje pitanje. Autonumber nije najsretnije rešenje za PK kod relacionog modela. Korisnika ne možeš da nateraš da ga unese prvog, jer je to posao Access Jet mašine, a ona to radi tek kad se izađe iz zadnjeg polja. Ja autonumber koristim samo tamo gde nisam zainteresovan za kasnije pretraživanje. Obično su to tabele činjenica u dimenzionim modelima i tabele u relacionim modelima kad nešto istražujem pa me mrzi da pravim validaciju koja mi kasnije neće trebati.

Ako nije kasno zameni sve te Autonumber kolone sa Number, Long Integer. Postavi validaciju kroz forme i automatsko dodavanje prvog većeg broja (n+1). Korisnik će imati osećaj da kontrola stvarno postoji. Ima dosta primera za to na forumu u temi Gotovi programi članova foruma. I koristi eksplicitnu validaciju. Option explicit u VBA modulima. To je samo savet. Inače je sve dobro iskompajlirano.

Taj Autonamber te je i naveo da sakrivaš podforme. Podforme su napravljene da budu sinhronizovane sa glavnom formom.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Prepravljam staru bazu jer sam gotovo došao do kraja i ovo moram ici postupno da prilagodim kako si mi predložio.

Sljedeći korak gdje sam zapeo mi je automatsko dodavanje TestID

probao sam sa ovim što sam našao ovdje na forumu


ali mi to ne odgovara jer ova procedura uvećava brojeve i dok skrolaš bez obzira što nema novih unosa.
Odjednom u tabeli imam beskonačno praznih unosa.

Imaš li kakav prijedlog?

Ne treba ti VBA procedura. U polju BrojUnosa na formi otvori Properties i u redu Default Value napiši:

= Nz(DMax("[BrojUnosa]";"NazivTvojeTabele");0) +1

Kad otvoriš formu i uđeš kursorom u to polje dobićeš ponuđeni broj za jedan veći od postojećeg. Ako odlučiš da ne završiš zapis, samo izađeš iz forme.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Private Sub Form_BeforeInsert(Cancel As Integer)
If Me.NewRecord Then
TestID = Nz(DMax("TestID", "tblTest")) + 1
End If
End Sub

Išao sam na BeforeInsert i izgleda da ce moci ovako.

Uključio sam Require Variable Declaration. Zamenio sam Autonumber sa Number i u formi dodao kod

Ovim se svaki put IDFaktura povećava za jedan. Problem je, koliko god puta kliknem na Next on dodaje novi IDFaktura. Ovo verovatno treba rešiti preko validacije ali nemam ideju. Vi rekoste da ima primera u Gotovim programima al nisam uspeo naći.

Ja sam to baš danas rijesio ovako

Private Sub Form_BeforeInsert(Cancel As Integer)
If Me.NewRecord Then
TestID = Nz(DMax("TestID", "tblTest")) + 1
End If
End Sub

Hvala, Miki. Ako ja dobro vidim ovome fali kad se klikne da se doda novi zapis da on to ne uradi. Možda bi trebalo na dugme za dodavanje novog zapisa staviti kod

Nije mi jasna validacija koju je pomenuo gospodin Getsbi. Ima li neki primer?

Pa nisi testirao... Kad klikneš novi unos "kao da se ništa ne dešava" međutim, čim uneseš bilo šta u bilo koje polje on se dodaje. A ako odustaneš od snimanja on se poništi. Probaj...

Probao, i to je tačno kad se bira nešto iz forme. Međutim, kad se bira nešto iz subforme javlja da nedostaje PK. Isti problem kao ranije.

Isprati ovu temu http://www.elitesecurity.org/t438557-0#2971236
Možda pomogne. Ima primer Brojac ZE.zip.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Čim sam se vratio kući vraćam se i vama sa pitanjima. Naime, mnogo više mi se sviđa Getsbijev predlog da umesto autonumber koristim number. Podesio sam da mi se npr. svaki put IDFakture inkrementira za 1. Kada pokušam da kroz formu Faktura odmah krenem sa unošenjem artikala javlja mi grešku You cannot add or change a record because a related record is required in table 'Faktura' iako je za IDFakture upisan npr. broj 9. Ako ja obrišem i ponovo upišem taj isti broj bez problema unosim artikle. Ima li rešenja?

Ako bi uneo još jedan podatak u formu Faktura, pa prešao na podformu Access bi snimio zapis i znao bi da su zapisi u podformi povezani sa zapisom na Fakturi.
Ako ideš odmah u podformu, na formi vidiš novi broj fakture ali to je podrazumevan vrednost, nije snimljen zapis. Kad napustiš formu, pogledaj u tabeliu, taj zapis nije upamćen.
Faktura svakako ima još neki neophodan podatak, datum, kupac ne vidim nio razlog da se unose stavke a da nije unet nijedan od tih podataka.

Sve ste u pravu što kažete, ja samo pokušavam da nađem način da korisnik odmah počne unositi artikle. Što se tiče razloga zašto odmah "napadaju" artikle ne znam, možda prvo hoće da vide cenu. Možda da ako se prvo klikne na artikle da se stavi upozorenje da se mora uneti datum, mada to nije ono što sam hteo.

Mislim da ne treba uvek uvažavati zahteve korisnika.
Ima načina da se uradi to što šeliš, ali ja nikako ne vidim svrhu toga, može da napravi probleme, a štedi jedan klik, umesto da se unese datum ili broj fakture ide se direktno na artikle, sava ušteda.
Ja sam uradio jedan primer kako se može raditi direktno sa artiklima, čisti kao ideju, u praksi nikada ne bih to koristio.
Inače, mislim da imaš i drugih slabosti u bazi, recimo, rad sa cenama iz tabele artikli. Šta akko se cena promeni, stare fakture neznaju koja je cena bila.

Slažem se sa kolegom BiloKoje.
Ti kao programer određuješ kako će se raditi unos i šta je prioritetno. Dokument se sastoji od zaglavlja i satvki. Ispoštovao si pravilo identifikujuće veze da je stavka egzistencijalno i identifikaciono zavisna od računa, da stavka mora da pripada jednom (One) računu i da račun može da ima jednu (One) ili više (More) stavki.
Unos u program možeš da zaustaviš (recimo zbog ispijanja kafe) posle popunjavanja zaglavlja koje se sastoji od: BrojRacuna, DatumRacuna, Isporucilac, Kupac......etc i to ima smisla. Nakon kafe ili sutradan, pokreneš aplikaciju i ona bi trebalo da te podseti ako postoje računi koji nemaju stavke. To se takođe može uraditi i ima smisla. Ono što nema smisla je da dozvoliš operateru da unosi stavke a da prethodno nije popunio zaglavlje. Praksa ručnog popunjavanja računa ili fakture gde se to ponekad radilo obrnutim redosledom nije baš poželjna u relacionim bazama podataka. Zamisli da sutra pokušaš da nađeš stavke koje nemaju zaglavlje. Nema primarnog ključa koji će da ih identifikuje.
Zato slušaj operatere i njihove želje samo ako imaju smisla. Ti se pitaš kako će program da radi.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Poslušao sam vaše savete, samo sam stavio upozorenje da se nešto mora prvo uneti u glavnoj formi. BiloKoje, potpuno ste u pravu što se tiče cena. Ovo je program kolege Fox028 na kojem se ja učim. Kako da se reši ovo sa cenama, jel treba neka tabela promena il nešto drugo?

Imali smo na ovom forumu u više navrata razgovor oko vođenja evidencije robe, ulaza i izlaza, praćenja stanja zaliha, fakturisanja prodate robe. Uvek postoji više načina da se posao obavi, koji je najbolji zavisi od konkretnog zadatka, stvar je znabha i veštine programera koji će pristup izabrati, naravno, uvek vodeći računa i o budućim dogaćanjima, kako se može program prilagoditi nekom novim okolnostima.
Konkretno, za jednostavan ulaz i izlaz robe ja bih napravio tabelu artikala koja bi saddravala šifru, naziv i cenu. Cena može biti nabavna ili prodajna ili obe. Zatim bih napravio tabelu Promene, koja bi sadržala pored ključa, datum promene, vrstu promene, recimo, nabavka, početno stanje, popis, manjak, višak, prodaja, otpis. Za tabelu promene bi bila vezana tabela StavkePromena, imala bi primarni ključ i spoljni ključ prema tabeli Promene. U stavke se unosi artikal iz tabele Artikli, količina, cena, eventualno popust, rabat, poreska stopa.
Baza bi imala i tabelu Komitenti, sadržala bi podatke o kupcima i dobavljačima.
Različite vrste promena koje sam pomenuo kod tabele Promene, takođe, mogu biti smeštene u jednu tabelu, pa da se u Promenama biraju sa liste.
Svaka vrsta promene proizvodi odgovarajući dokumenat, prijemnica, popisna lista, dostavnica, faktura.
Stanje robe bi se dobijalo pomoću upita, saberu se sve količine ulaza jednog artikla i oduzmu se sve količine sa izlaze stavke. Upit bi davao karticu artikla.

Naravno, ovo je samo jedan od načina, i to je malo grubo nabacano, pre početka rada na programu treba što detaljnije analizirati poslovanje, postupke, dokumentaciju pa se odlučiti za jednu šemu iz koje se posle dolazi da tabela, kolona, tipa podataka, relacija.