Okacite Vas primer, lakse ce se pomoci.

Poštovanje, Zorane! Ovo je baza koju sam uradio do sada. Potrebna mi je pomoć za izradu "korak po korak", a na kraju potrebno mi je da mogu da pratim stanje kroz unos podataka o ulazu i izlazu i, naravno, uvid ulaza, izlaza i stanja robe u magacinu po vrstama. Radim u Access-u 2010.

Opet pcpopovic, nisam poslao bazu (prvi put sam na forumu), Ne znam gde da "okačim" fajl baze (6 Mb).

Možemo dalje, "prikačio" sam fajl, hvala!

Na prvi pogled, verovatno ste mislili na formu "frm_Banke" i problem ComboBox-a "IDMesto". Nije dobar upit, verovatno ste ranije imali drugu tabelu pa je tabela Mesto imala kljuc ID i ostala je ta referenca te sam to korigovao. Desava se to i nama matorijima, ali tu nije glavni problem. Veci je problem u modelu Vase baze. Kao sto rekoste da ste pocetnik pa to se od pocetnika i ocekuje. Ako zelite da uradite aplikaciju koja treba da isprati funkcionalnosti iz realnog zivota, morate zadovoljiti dosta pretpostavki. O tome je bilo vec govora na ovom forumu i mozda ne bi lose bilo da prvo to procitate http://www.elitesecurity.org/t166884-0#2720176.
Nakon toga bih Vam preporucio knjigu prof. dr Alempija Veljovica http://www.cafe022.com/mybb/ra...lempije-veljovic-246-t-37.html

Pročitao sam uvod u Access forum i pridržavam se toga od samog početka. Uvideo sam problem od malopre i popravio izvor podatka, ij, poziv na tabelu i polje u formi Banke. Isti problem imam i sa formom OtkupnaMesta, ali ja tu u svojstvima ne vidim u kartici "Podaci" gde bih popravio izvor retka koji treba da mi omoguće unošenje podataka za ulicu i mesto (IDUlice i IDMesto). Molim Te da mi ovo objasniš detaljnije (samu grešku i njeno ispravljanje). Upravo sam "skinuo" Alempija Veljovića i doda ga u obaveznu literaturu. Inače već čitam uporedo tri Access štiva (dva elektronska i jedno štampano). Hvala na trudu i vremenu!

Zaboravio sam da dodam jos nekoliko zapazanja:

1. Izbegavam na nivou tabele, da polju koje je vezano za neku tabelu (sifarnik) putem relacije "strani kljuc" dodelim osobinu Lookup "List Box" ili "Combo Box", vec ostavljam da je tipa "Text Box".
2. Licno izbegavam da koristim imenovanje tabala, kolona, formi, Reporta primenom madjarske noatacije. Opet kazem, licno smatram, da nema smisla trositi energiju i vreme na svaki prefix tbl pa jos i donja crta tbl_Banke, frm_Banke itd. jedino sto kod Query-ja dodajem ispred najkrace moguce Q... Takodje svim objektima imena dajem u jednini kako je pok. prof Branislav Lazarevic govorio. Vidim isto da ste nazive atributa koji su kljucevi dodeljivali (npr IDMesta), ja licno preporucujem da koristite MestoID.
3. Da li neko ko je prodavac u jednom trenutku, moze i da bude kupac u drugom trenutku. Mislim da dokument (Prijemnica, Otpremnica) odredjuje da li je neko prodavac ili kupac sto znaci da objekti Kupac i Prodavac u sustini predstavljaju jedan objekat kojeg bih krstio PoslovniPartner ili prostije Partner.
4. Vise puta sam govorio o oznacavanju predmeta poslovanja i klasifikaciji predmeta poslovanja pa obratite paznju oko toga.

Evo mali dodatak pocetku...

1. Slažem se, ali kako posle da postavim relaciju između polja PK (koje je tipa broj - recimo, IDMesto) sa povezanim poljem u drugoj tabeli (koje bi bilo tipa tekst - i koje treba da mi "vuče podatke" iz prve tabele) i koje FK, kad mi Access to ne dozvoljava. Da drugačije povežem tabele?
2. Ove primedbe ću prihvatiti.
3. Slažem se, ali mislim da je meni, kao početniku ovako preglednije "ko šta radi" i "ko je ko".
4. Ovo mi nije baš najjasnije na čega se odnosi.
Druže Eremija opet mi nisi odgovorio na konkretno pitanje oko forme OtkupnaMesta, gde ne mogu da vučem podatke za Mesta i Ulice. Gde sam pogrešio i šta to ne vidim (svestan sam toga koliko ne znam). Opet šaljem bazu.

Da krenem od poslednjeg, imate u prilogu kako treba...

A sto se tice tacke 4. oznacavanja predmeta poslovanja i klasifikacije imate pored linka koji sam vam vec dao i na linku primer klasifikacije http://www.elitesecurity.org/t303936-1#2548275

Molim za objašnjenje postupka popravke moje forme (korak po korak), jer se bojim da ću taj problem imati i prilikom kreiranja narednih obrazaca. Hvala!

Ljudi, nije valjda da niko neće da mi pomogne da nastavim rad i učenje dalje! Moj trenutni problem je forma OtkupnaMesta gde ne mogu da unosim povezane podatke za ulice i mesta; kao i forma Proizvodjac gde mi se ne dozvoljava unos povezanih podataka za naziv mesta, naziv banke i naziv otkupnog mesta. Nemojte mi samo popravljati bazu - nego mi i objasnite kako da ispravim sam grešku. Šaljem trenutnu verziju baze. Help i HVALA!

Na forumu možeš očekivati pomoć u smislu da ti neko ukaže na grešku ili ti popravi prikačeni fajl. Malo je pretenciozno očekivati da će neko da te vodi korak po korak do kompletiranja aplikacije. Za učenje korak po korak služi knjige. Jedna se upravo tako i zove. Knjiga Microsoft Office Access 2007 edicija "Korak po korak", autor Stiv Lambert, M. Dau Lambert, Džoan Peperno izdavač CET. Postoji i prethodna verzija za Access 2003, a možda i novija za Access 2010. Ovo zadnje nisam siguran.

Uostalom koliko sam čuo od kolege Zorana, on ti je na mail poslao .avi fajl sa objašnjenjem postupka popravke tvoje forme.

Za učenje prvenstveno koristi knjige.

Dubokopoštovani Eremija! Hvala Ti na trudu. Obećavam da ću i ja jednoga dana kada postanem "matori" (majstor zanata) pomagati drugima. Zahvaljujem se i velikom Getsbiju, jer da ne bi njegove poruke, ne bih ni video da Tvoja poruka ima dodatak.
Sad o poslu.
1. Sve sam uradio kako si mi objasnio, čak sam i uporedio postavke Tvoje forme OtkupnaMesta sa mojom, ali ja nikako ne mogu, izborom na padajuće liste Ulica i Mesta, dobiti nazive (tekstualne) odabira - "izađe" mi brojčana vrednost izbora - ID. To je u redu za tabelu, ali u formi bih trebao tekst.
2. Pokušao sam sam urediti formu Proizvođač i prilično sam (ne)zadovoljan mojim radom, ali...
- Naziv ulice valja iz prve, pa tu ne diram ništa.
- Naziv mesta ne valja. Prvo mi traži unos parametara tablice. Kad mu kažem "OK" ne desi se ništa novo. Koje parametre?
- Naziv banke sam sređivao i došao sam do toga da imam listu, ali nakon unosa mi "kaže" da "može samo broj."
- Kod naziva otkupnog mesta u listi imam dve kolone: ID i Otkupno mesto, gde nakon izbora u okvir smešta broj (ID), a ne tekst (naziv otkupnog mesta).
Šaljem Ti dva dodatka: jedan poslovni i jedan lični.
POZDRAV!

Uglavnom sve se svodi na istu gresku u prilogu sam naveo slike kako je i kako treba...

Hvala, čak i kapiram šta čemu služi. Idem dalje - čujemo se kod sledećeg HELP-a!

Pozdrav Eremiji, Getsbiju i dr!
Završavam forme i imam nekoliko pitanja. Ali pre toga mislim da treba da ubacim proizvođača kod prodaje, jer se mora pratiti čija se i koliko robe prodaje, da bi se znalo, isto tako, i čije i koliko robe ima u hladnjači na stanju. Ja sam to ubacio u tabelu OtpremniceDetalji - jel to u redu?
Kako mogu u formi da dodam automatsko polje? Recimo u formi Zaduženje ambalaže da kada unesem prezime proizvođača za zaduženje, da mi automatski u narednom okviru izbaci i njegovo ime?
Nisam se do sada javljao jer sam se bavio literaturom, samu bazu sam radio ispočetka zbog normalizacije i relacija - mislim da je malo bolja nego pre, a i ovu aplikaciju sam radio u excel-u, zbog potrebe posla, i završio (šaljem Ti i taj fajl - aplikaciju na komentar i da vidiš da nisam apsolutni početnik, ali moram preći na Access). A šaljem i bazu na kontrolu,

I još jedno važno pitanje!
Kako da sredim da prilikom prodaje (izlaza) određenog proizvoda od određenog proizvođača, prilkom unošenja u formu OtpremniceDetalji (mislim da se te stavke trebaju tu evidentirati) izbegne to da se može više prodati nego što ima u magacinu - hladnjači?

Rešio sam automatsko polje za prezime u formi tako što sam kopirao polje imena i u njemu (u SQL-u) odobrio samo ID i prezime. Da li je to to ili treba drugačije?

jel to radiš aplikaciju za sebe ili za firmu... jel ovo baš i nije aplikacija za početnike

Rekao (napisao) sam negde na početku. Namera mi je da naučim i usavršim baze podataka, pre svega - Access, uz pomoć literature, primera i dobrih i mudrih ljudi (i žena) na mreži. Po vokaciji sam profa u školi, tako da para za dodatno lično školovanje nemam (paradoks - ali tačan). Što se tiče aplikacije s kojom sam počeo - jasno mi je da ne spada u najjednostavnije, ali što komplikovaniji početak - više se stvari nauči za kraće vreme. A prva moja baza? Pa ko zna, ako dobro "ispadne", možda će i naći svoju drugu svrhu (osim obrazovne).

Eremija i ostali koji imate vremena, volje i znanja!
Stigao sam (uz mnogo literature, primera i moje "patnje" uz - stani, kreni, obriši, napiši, probaj, proveri, zakljući, dovedi u vezu ovo sa ovim i ono sa onim,...) do pred kraj obrazaca u mojoj bazi. Trenutno imam samo jedno pitanje iz dva dela:
- U formi ZaduzenjaRobe nikako mi u Ceni robe ne vide se cene svih roba (sad se ne vide sadnice kajsija) i
- U toj istoj formi Ukupna cena koštanja mi nikako ne daje pravi rezultat.
Šta to ne vidim i ne znam, a treba da vidim i da znam? Molim za pomoć da mogu dalje!

Kako rece ono u filmu "Ivkova slava"?
Moze li ona pesma "Nesanica", a muzikant odgovara "Kud nadje tu najskuplju"?!?!?!? :-)

Daklem ako uzmemo pretpostavku da je model podataka "DOBAR" i ne udjemo u tu bit...

U tabeli "opet ono tbl_ ?!?!?!?", tbl_ZaduzenjaRobe obrisao sam Vam Default Value u poljima IDProizvodjaca, IDRobe, IDJedinicaMere i IDCenaRobe ge je bila vrednost 0.
Zatim u formi "opet ono frm_ ?!?!?!", frm_ZaduzenjeRobe ubacio sam Vam kod

Private Sub IDCenaRobe_GotFocus()
Me.IDCenaRobe.Requery
End Sub

Private Sub IDRobe_AfterUpdate()
If IsNull(Me.IDRobe) Then
Me.IDCenaRobe = Null
Else
Me.IDCenaRobe.Requery
End If
End Sub

Objekat ComboBox IDCenaRobe je bio pogresno referenciran na polje IDRoba.

U istom objektu sam promenio Row Source na

SELECT tbl_CenaRobe.IDCenaRobe, tbl_CenaRobe.Cena FROM tbl_CenaRobe WHERE (((tbl_CenaRobe.IDRoba)=[Forms]![frm_ZaduzenjaRobe]![IDRobe])) ORDER BY tbl_CenaRobe.Cena;

Polje Ukupno korigovao sam Control Source

=[Kolicina]*[IDCenaRobe].[column](1)

A cena za IDRobe=3 "Sadnice kajsije" i ne moze da se vidi jer IDRobe=3 ne postoji u tabeli tbl_CenaRobe.


_{[Ovu poruku je menjao Zoran.Eremija dana 07.08.2011. u 12:59 GMT+1]}

Bravo Care!
- "tbl" i "frm" neću više stavljati, ali ako sada promenim nazive tabela i formi - mislim da ću poremetiti čitavu aplikaciju:
- Gde god je u spoljnom kljuću bila zadana vrednost "0" obrisao sam;
- U formi ZaduzenjeRobe polje Ukupno je OK, mada bih voleo znati na šta se odnosi dodatni deo izraza - ".[column](1)";
- Kod nisam primenio, jer polje Cena robe sam sredio na drugačiji način od onog kako si mi Ti objasnio. U Tvom
primeru nešto nije OK. Ustvari, zato što sam ja bio nešto poremetio (hvala što si video) u tabeli CenaRobe (to sam
popravio). Mada mi nije jasno kako mi je Access dozvolio da menjam podatke i da mi se neki podaci ne poklapaju, čak
i dupliraju - a svaka veza mi ima referencijalni integritet.
Pitanja:
1. Zašto mi podaci iz forme ZaduzenjaRobe ne vide se u tabeli ZaduzenjaRobe? Ne vidi se IDCCeneRobe i
IDJedinicaMere? Sada mi forma radi kao "Singerica" - a šta ću sa tabelom?
2. Tvoja baza ima oko 2 Mb a moja oko 10 Mb (ovo i nije trenutno jako važno)!?
Pozdrav!

Ovde se radi o objektu "IDCenaRobe" koji je tipa combobox i njegov Control Source je upit koji kao rezultat vraca 2 kolone kolonu IDCenaRobe i Cena. u njemu su poredjane upravo tako gde Access prvu kolonu oznacava sa IDCenaRobe.column(0), a drugu IDCenaRobe.column(1), a posto je u drugoj koloni vrednost cene koja nam je potrebna zato je za polje Ukupno referencirana ta kolona "=[Kolicina]*[IDCenaRobe].[column](1)"



E tu je problem modela podataka. ako ste robi dodelili jedinicu mere onda nema smisla da se ona pojavljuje u bilo kojem drugom dokumentu tj tabeli. Iako sam prepravio Row Source koji je bio nevaljan referenciran je na IDRoba, kao i Control Source ovog combobox-a.



Tacno je jer sam uradio Compact & Repare tj u opcijama sam cekirao da se radi Comapct nakon zatvaranja baze

Da, to je to!
- Modelovanje podataka u bazi tek sada počinjem polako da shvatam. Uviđam da imam određeni broj polja podataka koji mi se nepotrebno ponavljaju u nekoliko tabela.
Da li bi se nešto strašno desilo kada bi, na primer, iz tabele ZaduzenjeRobe uklonio polje JedinicaMere (sa prethodnim brisanjem relacije)?
Jasna su mi pravila normalizacije baza, ali ta pravila tek "vremenom i iskustvom dolaze na svoje mesto".
- [Forms]![frm_ZaduzenjaRobe]![IDRobe] - Šta "kaže" ovaj kriterijum?
Pozdrav.

Osim poznavanja baza, treba da znaš svašta nešto još. :)

Npr. dok sam radio u knjigovodstvu naučio sam da jedinica mere ne sme nikako da se menje, inače se to zove proizvodnja, a ako firma nije registrovana za proizvodnju eto belaja očas posla. Ako si npr. šećer kupio na litre, ne smeš da ga prodaješ na kg. To je super logično, inače se otvara prostor za malverzaciju.

To ne kažem iz nekog drugo razloga do - jedinica mere je stalan podatak koji nema potrebe da se ponavlja, inače se otvara mogućnost grešaka onog ko unosi, a ti posle objasni inspekciji da "nisi normalizovao bazu".

Ovaj kriterijum kaze da iz tabele tbl_CenaRobe ponudi samo one n-torke (redove) IDCenaRobe, Cena kojima je IDRoba jednako izabranoj robi u objektu forme "[Forms]![frm_ZaduzenjaRobe]![IDRobe]".

Završavam forme sastavljanjem obrazaca za prijem i prodaju robe - tri pitanja.
1. Formiranjem obrasca "Prijem voća", koji će činiti podaci iz dve tabele: Prijemnice i PrijemniceDetalji dobijam dva polja IDPrijemnice, jedno je samopopunjavajuće (AutoNumber) - a šta ću sa drugim koje je spoljni ključ? Da li to polje terba da se vidi u obrascu; Da li se popunjava i na koji način? Ili nešto treće? Isto će mi se pojaviti i kod obrasca ProdajaVoca.
2. Kako da postignem da mi sa u, naprimer, ComboBox-u Otkupno mesto, gde imam samo dve mogućnosti, prilikom svakog narednog unosa sloga automatski ponudi (otvori) jedna od mogućnosti (u ovom slučaju "Donji Tavankut")?
3. Zašto mi se oznaka za kalendar (za manipulaciju datumima) ne vidi kod svakog polja čije je tip datum/vreme?
Pozdrav!

Okacite primer da vidimo sta ste uradili.

Evo nešto sam uradio, čak sam i zadovoljan (delimično). I sve bi bilo OK, međutim...
Obrasci su završenim ostalo je još da ih doteram vizuelno. Bitno mi je da sam kontrole uradio. Problemi su sledeći:
1. Kad popunim i hoću da zapamtim unose u obrasce PrijemVoca i ProdajaVoća dobijam poruku da izvršim metodu Update ili CancelUpdate i AddNew ili Edit i ponište mi se upisi za proizvođača i datum; A zatim "kaže" da indeks ili primarni ključ ne mogu sadržavati vrednost "null". Šta je sad, ne znam koji ključ i od čega?
Ove tabele (čiji su obrasci o kojima se radi) su nastale kao potreba razbijanja veze "više na više". U obrascima sam sastavljao sva polja iz tabels Otpremnice i OtpremniceDetalji, kao i Prijemnice i PrijemniceDetalji. Možda je trabalo raditi subforme, ili...
2. U formi ProdajaVoca mi je neophodno "nešto" čime bih pratio prodaju voća po poreklu, odnosno, po proizvođaču.(dobavljaču) Ustvari, svaku prodaju moram vezati i za određenog proizvođača, kako bih kasnije mogao imati uvid u stanje lagera po proizvođačima;Takođe mi je potrebno da se "ne dozvoli" prodaja određene (bilo koje) količine nekog voća od nekog proizvođača - ukoliko toga (i toliko) nema u hladnjači (lageru, magacinu).
3. Da li još negde vidite neku neoprostivu grešku?
Pozdrav, krećem na Upite.

E sada je došao trenutak da se vratite na sami početak, tj. preporuke koje sam Vam ranije davao.

Model baze svakako nije dobar.

Da bih Vam odgovorio na postavljena pitanja i eventualno predložio šta da radite, možete li da opišete šta je to "Otkupno mesto" i zašto ste ga vezali i za kupca i proizvođača i za Otpremnice Detalji i prijemnice detalji?!?!

Da li prilikom prijema može da se dogodi da od jednog te istog proizvođača možete primiti i Voće i Robu i ambalažu i Avans ?!?!

Pozdrav.
Stvarno sam se od početka trudio da bazu isplaniram na svim nivoima i po svim zahtevima. Verovatno nisam pogodio baš sve, ali... Inače i proces rada jedne hladnjače mi je dosta poznat.
1. OtkupnoMesto bi bila pojednačna hladnjača (magacin) "negde" u nekom mestu u vlasništvu iste firme koja ima veći broj hladnjača, znači može biti u Tavankutu, Ritopeku, Lajkovcu, dve u Vršcu, itd. Može i svaka hladnjača (mesto koje prima - kupuje, voće od proizvođača, odnosno, Seljaka - lageruje ga, a zatim ga prodaje kupcu) da ima samo svoju bazu, ali u tom slučaju šta ćemo sa evidencijom prometa na nivou celog preuzeća (firme, zadruge)? Znači imao sam u vidu da se u svakom trenutku na nivou cele firme može pratiti poslovanje po pojedinačnim otkupnim mestima. Za mene su to pojedinačni subjekti koji rade isti posao, ali ujedno i čine jednu celinu. Sledi da, osnovni entiteti baze (Proizvođači, Voće, Kupci) moraju uvek biti vezani i za otkupno mesto.
2. Da, proizvođač može biti i kupac (i obrnuto). Naravno, nikad svoje robe (voća).
- Voće (rad sa njim) ima tri faze. Ono se otkupljuje (kupuje) od proizvođača, zatim se lageruje u hladnjaču (magacin) i na kraju se prodaje kupcu.
- Ambalaža (gajbe) se samo zadužuju, a zatim vraćaju. Njih zadužuje i vraća proizvođač.
- Robu čine, npr, sadnice, hemijska sredstva, veštačko đubrivo, plastična folija, materijal za navodnjavanje, itd., koju proizvođač "dobija" od hladnjačara, koja uvek ima svoju cenu i koja se - suma cene koštanja (znači proizvođač može da uzme nekoliko stvari) na kraju, kada se voće proda, prilikom isplate cene voća proizvođaču odbija, odnosno zaračunava od sume novca koji mu se isplaćuje.
- Avans je "pozajmica" (novčana) od hladnjačara prema proizvođaču. Koja se (iznos Avansa), takođe na isplati, odbija od novca koji, na kraju, hladnjačar isplaćuje proizvođaču za preuzeto i prodato voće.
Formula za isplatu novca bi glasila: Novac koji hladnjačar isplaćuje proizvođaču za otkupleno voće, a nakon prodaje tog istog voča = Ukupna suma cene koštanja otkupljenog voća - (Zadužena Roba + Avans).
Nadam se da sam pojasnio!

A sto prva aplikacija nije bila u tvojoj bransi, ipak si profa u skoli , pa mozda neka baza za vodjenje evidencije ucenika koji idu na dodatnu nastavu.

Nema veze ako zelis "prodati" svoju prvu aplikaciju, ali mi se cini da nam ne govoris istinu..

Sory ... morao sam ... reagirati

Poštonani gospon Trtko!
1. Uopšte i nije jasno zašto Ti uopšte i reagiraš svojim komentarima u ovoj temi. Malo su iritirajući tvoji komentari i pitanja, prilično lična. Mislim da ne kršim nijedno pravilo foruma, niti mi je to cilj. Samo hoću da nešto naučim, napredujem, a bude li usput i neke koristi - pa dobro došlo.
2. Budem li se hteo ispovedati, to ću učiniti (prvi put u životu) u crkvi kod Oca-Prote Dušana. nikako ovde "nekome" na forumu.
- Izvinjavam se svima koji me prate, na pravi način na ovom forumu i od kojih imam veliku pomoć i podršku, na grubim rečima, ali stvarno me nerviraju neke stvari.
- Obećavam da više neću odgovarati na ovakav način (a ustvari neću odgovarati nikako) ni na šta što nema veze direktno sa temom.
Pozdrav!

Pozdrav za Miroslva i želim mu da nauči na ovom forumu sve ono što mu je neophodno da postane majstor akcesa.
Zoran ima neviđene živce da odgovara i pruža pomoć na forumu i po tome je poooznat i hvala mu.
Ali Miroslave zapitaj se zašto se niko drugi ne uključuje u tvoju temu.
Prvo: ona je već prežvakana tema tipa magacinsko poslovanje
Drugo: ona je ogromno zahtevna i traži znanja ne samo iz programiranja već i iz knjigovodstva-analitika,sintetika,porezi...
Treće: Okačili ste link ka svom sajtu http://pcpopovic.webs.com/ na kome se očigledno vidi da je vama oblast davanja usluga u opisu radnog mesta .Pa je i sumnja da vi vršite uslužnu delatnost iz oblasti programiranja veoma opravdana.
Četvrto: baza koju radite je specifična tjs. namenska i zato izaziva podozrenje.Obično se za početak uzima neki primer magacina tipa biblioteka gde se može jasno odrediti ulaz i izlaz,kao i ostale reference. Ovo vaše je previše komplikovano zbog ulaznih faktora a to znači da se radi o realnom životu

Na dam se da sam vam pomogao da razjasnite bar nedoumicu zašto ste nekima na ovom forumu-krivi

Slušajte Zorana i napravićete tu bazu ali i to neradite već brzate a u akcesu verujte sve greške sa početka ,usput narastaju,pa se na kraju mora raditi ili iz početka ili sve menjati.
Naučite se na nečemu lakšem.
Ako mogu da pomognem tu sam,iako malo vremena imam.U poljoprivredi mi ne treba akces osim za vođenje troškova i dobiti a to eto nije loša ideja za početnika. Dovoljno je definisana baza sa realnim ulazima i izlazima i velikom mogućnošću proširenja. Probajte nešto malo tipa Uzgoj pet koka nosilja

Pozdrav Galac 1968!
Ipak ću uneti razjašnjenja i objašnjenja.
1. Pored toliko tema ovog tipa, koje pratim koliko god mogu, otvorio sam "još jednom", jer sa postojećih tema uzimam stvari koje su meni razumljive, a svaki "težak korak", koji ne mogu da pronađem, moram da pitam i ujedno da mi bude jasno - šta je šta i zbog čega je šta.
2 i 3. Da, to mi je jasno (da je aplikacija zahtevna), ali ideja se pojavila kao potreba da pokušam preko teških primera, naučiti raditi i lakše stvari (takav mi je horoskop). Ujedno, živim u voćarskom kraju gde sam procenio da, ako ovo uradim jednog dana, možda i poboljšam svoj status. U razgovru sa prijateljima već duže vremena imam sugestije da počnem i izradu aplikacija, koje će naći svoju primenu u realnom životu, kao i da unapredim svoje znanje na polju Informacionih sistema.
Da, imam malu porodičnu firmu koja popunjava "rupe" iz moje prosvetarske plate. U oblasti računarstva sam negde od 1993. godine i za to vreme sam postao "mali majsor" za hardver i veći broj programa. Vremenom Sam postao i "veliki majstor" rada u svim Office programima (osim Access-a) i dizajnerskim alatima, pre svega u QuarkX-u. Pošto sam profa predmeta koji nema baš mnogo veze sa Informatikom, kompletna znanja koja imam u toj oblasti su rezultat mukotrpnog rada, rada i samo rada uz učenje do besvesti. Mislio sam da nikad neću ući u Baze i Programiranja, ali život to zahteva, a i mislim da sam u ostalim oblastima mog interesovanja stigao neki optimum.
Na kraju krajeva, da se ne lažemo, mora se i živeti od nečega.
4. Da, baza je namenska (upotrebljiva i potrebna), jer moj pokretač u ovoj oblasti bio je moj mladi prijatelj, inače bivši učenik, vlasnik hladnjače, kada je rekao: "Nastavniče Vi to ne umete da uradite, šta to za Vas?!", koji mi je nekoliko puta, poslednjih godina, pomogao kada mi je bilo potrebno.
- Slušam Zorana kao Sveca!
Hvala na podršci!

Cast svakome, ali malo dostojanstva i pristojnosti nikome nije na odmet.
Takav nacin obracanja clanovima (pogotovu jednom od kojeg moze dosta da se nauci Trtku) mislim da nije u redu.
Nije tesko biti fin. Probajte.

Uopšte nisam imao ni ideju da budem nepristojan ni prema kome, posebno stoga što znam da sam nov na forumu, i posebno ne prema velikim majstorima koji me prate na forumu.
Možda sam malo nestrpljiv.
Ajmo ljudi, ispadoh "najgori" - a ne znam zašto.
Ja bih da krenem dalje i pored svih "grdnji". Nemojte da mi se tema pretvori u čitanje psiholoških profila. Ajmo na Access!
Posebno izvinjenje Trtku, ukoliko sam bio na bilo koji način netolerantan u obraćanju.
Pozdrav!

Dugo sam se razmišljao koji koncept da Vam predložim.



Upravo ovo što kaže kolega @galac1968, mi je bio ograničavajući faktor šta da predložim.
Pa ajde da malo zakuvamo stvar sa priloženim modelom.



Vaš problem u realnom svetu jeste malo specifičan, ali u samom startu se prenebegava činjenica o jedinstvenom sistemu označavanja i to najvažnijeg objekta posmatranja "Predmet poslovanja".

Ma sve OK, sad nam sve jasno, nisam imao nikakvih loših primisli.
Pomagat ću i ja ako gdje zapne u bilo ćemu , pa access sam ja "izumio".

Sad sam se i ja bacio u voćare , uzgajam Aroniju,

bilo je prijašnjih godina slućajeva na ovom forumu kad su preko nas forumaša ljudi htjeli napraviti aplikaciju i prodavati je..

zato sam reagirao, i zato se ne ljuti na mene @pcpopovic

Pozdrav

Na Access forumu postoji bar desetak, a možda i više, dobrih poznavaoca Access-a. Neki od njih su to postali upravo prateći ovaj forum. Vredi poslušati one koji tvrde da se ne treba upuštati u rešavanje kompleksnih poslovnih problema u fazi učenja. Ova faza kod Access-a, za razliku od ostalih aplikacija iz Office paketa, traje mnogo, mnogo duže. Razlog tome je svakako što je Access Database management sistem sa poštovanjem pravila relacione teorije, a ne prosta aplikacija koja se može savladati u jednosemestralnom kursu. Strpljenje je više nego neophodno. Pogotovo strpljenje početnika u pretraživanju foruma za neophodnim odgovorima.

Zoran je dao model baze onako kako ga on vidi iz svoje perspektive, a na osnovu do sada dobijenih informacija.

Ni meni se pitanja koja se ponavljaju ne sviđaju mnogo i kolega Zidar i ja "gumicu" koristimo samo u krajnjoj nuždi. Trudite se da ne izlazite iz okvira zadatih tema. Ovu ću preimenovati u "Otkup, skladištenje i prodaja poljoprivrednih proizvoda", pa ćemo videti kako će se dalje razvijati.

Getsbi, slažem se i, naravno - prihvatam. Idemo dalje!
Zorane pregledao sam Tvoj model baze, rekao "UH!", prihvatio koncept, jer su svi entiteti, koji su mi potrebni za rad tu, i krenuo u formiranje baze od početka.
Čujemo se uskoro, pozdrav LJUDI!

Ako je tako, evo ga nastavak do tacke do koje sam imao volje :-)

Da li ste ovo zeleli?!? Pogledajte formu PartnerLista

Zorane, moji hvalospevi Ti nisu neophodni. Svaka Čast Majstore!
Daj mi malo vremena da proučim šta si sve uradio i na koji način, da bih Ti mogao odgovoriti šta ne štima i, pogotovo, šta meni nije jasno.
Forma PartnerLista je savim po meri. Kompetna evidencija, u malom, na jednom mestu.
Za početak, nejasnoće su sledeće:
1. Nedostaje NazivAmbalaze u tabeli Ambalaža, jer proizvođač duži ambalažu prema vrsti i po broju komada, a težina ambalaže služi da bi se njom (težinom) manipulisalo kod otkupa i prodaje voća. Voće se prima u ambalaži (gajbe), a tako se i lageruje i prodaje. A zatim se od ukupne težine (tara) odbija težina ambalaže da bi se dobila neto težina voća u svakom koraku. Znači "Stantić Branko" ne može da duži 547 kilograma ambalaže Holandez - on može da duži 547 komada Holandez ambalaže;
2. Zar ne bi u tabeli Partner trebala kolona (polje) za tip partnera - da li je kupac ili je proizvođač?
3. Nije mi, na prvi pogled, baš najjasnije zašto si tabele za voće, sorte i klase voća onako namestio, ali videću tokom rada. U svakom slučaju nedostaje kod tabele Voce naziv voća, jer voće uvek mora da ima naziv (vrstu) i da bude za njega vezano i ostalo: i vrsta (npr. Jabuka) i sorta (npr. Ajdared) i klasa (npr. Extra), a kod otkupa za to sve mora da bude vezana i otkupna cena;
4. Nema tabele CenaVoca. Misalim na otkupnu cenu. Ova cena uvek mora biti formirana pri prijemu voća, a može da se menja u nekom narednom periodu;
5. Nije mi jasna grafička oznaka kod pregleda relacija (gledam onaj .png). Iznad tabela Voce i Ambalaza imaš neki krug i "VrstaPredmetaPoslovanjaID". Nije mi jasna ta relacija koja ide od tabele PredmetPoslovanja (ili ka njoj);
Zasada toliko. Krećem u ličnu, ponovnu, izradu baze - od nule, "tvojim koracima", pa gde zapnem i gde mi se učini da nešto nije na mestu po mom modelu - eto me sa pitanjima. Nemoj očekivati da bazu uradim za dan-dva. Trajaću ja neko vreme.
Pozdrav!

I ne treba da stoji u tabeli Ambalaza NazivAmbalaze, jer je Entitet Ambalaza, specijalizovan entitet od entiteta PredmetPoslovanja. Znaci taj naziv stoji u tabeli PredmetPoslovanja.
Pravilo je da PredmetPoslovanja ima osobinu jedinice mere, ako sam lupio neku jedinicu to je iz razloga ne poznavanja materije.



Ovo nema smisla jer jedan te isti partner moze biti i proizvodjac i kupac. Da li je neki partner kupac ili proizvodjac (dobavljac) odredjuje vrsta dokumenta.



kao i Ambalaza i Voce je specijalizovan entitet od entiteta PredmetPoslovanja i on ima u sebi naziv. U ovom primeru se vidi nedostatak identifikacije predmeta poslovanja, kao i njegovog oznacavanja. Svaki predmet poslovanja mora da ima standardizovan naziv i u nazivu jos eventualno 2-3 najbitnije karakteristike. Na taj nacin se jednoznacno odredjuje predmet poslovanja i dobija jedinstveni ID i kao sto kazete ima svoju cenu.



Svi predmeti poslovanja imaju svoju cenu pa i Voce zato sam Cenu ugradio u tabelu PredmetPoslovanja i ona u biti predstavlja poslednju cenu. Za pocetak Vam je to sasvim dovoljno.



knjiga prof. dr Alempija Veljovica http://www.cafe022.com/mybb/ra...lempije-veljovic-246-t-37.html

OK. Bojim se da mi ne bude previše informacija za jedan dan. Nastavljam sutra. Pozdrav!

Da dodam jos malo informacija...

Samo da javim za video materijal. Izvinjavam sa - moja greška, to sam dobio odavno. Nego me zbunila informacija za PP kod mog naloga u vezi tog materijala, koju sam pročitao tek danas, a nisam pogledao datum poruke. "Prelistavam" ZE9.
Pozdrav!

Zašto su svi ključevi ID - "broj" (tip podatka), bez obtira na to da li su primarni ili spoljni ključevi, nema AutoNumber? Nije mi jasno pravilo i koja je upotrebna svrha? Kako oonda dalje pratiti relacije tabela? Mora li se u svakom tranutku znati napamet kompletan odnos između tabela u bazi?
Pozdrav.

Da (setih se), razlika mi je jasna u vezi primarnog ili spoljnog ključa, zavisi (i po tome se zaključuje) od indeksa. Ali ipak bi voleo čuti zašto kod primarnih key-ova ne koristiti AutoNumber?

Kako je moguće da sam uspeo da postavim primarni ključ, a i spoljni ključ je sledeća stavka, (pratim Vaš rad) u tabeli DokumentStavka a da ne mora biti i indeksiran i jedinstven i zašto se to radi? Ustvari jasno mi je kako sam to ja uradio (jasan mi je način postavljanja ključeva), nego mi nije jasno kako je to Access dozvolio?

Zar ne treba u tabeli DokumentStavka da prvo polje (i primarni ključ) bude "DokumentStavkaID"? Kod Vas je "DokumentID". A takvo polje, isto sa primarnim ključem, postoji i u tabeli Dokument.

U praksi sam se susretao sa raznim situacijama pa mi je tip podatka Autonumber samo stvarao probleme. Autonumber koristim samo u slucajevima prostih potreba, kada nemam vremena da se time bakcem i iz tog razloga ga stvaram svojim kodom.

Entitet DokumentStavka je egzistencijalno zavisan od entiteta Dokument odnosno predstavlja slab entitet u odnosu na Dokument. Primarni kljuc entiteta DokumentStavka cine atribut DokumentID koji je prenesen kljuc od entiteta Dokument i kao drugi atribut je PredmetPoslovanjaID. Zajedno cine jednoznacnost s jedne strane a s druge egzistencijalna zavisnost sa entitetom Dokument je cvrsto definisana. Entiteti Dokument i DokumentStavka su u cvrstoj egzistencijalnoj vezi sa osobinom kaskadnog prenosenja. Ako entitet DokumentStavka dalje u modelu nema vezu sa nekim drugim entitetom u odnosu Roditelj-dete onda je ova veza i definisanje zdruzenog kljuca opravdana.

Ako ja, kao učenik dobro razumem, tu se ujedno vrši i razbijanje veze "više prema više".
Može li pojašnjenje polja KlasaVocaSort u tabeli KlasVoca. U relacijama ne vidim direktnu vezu, ali mislim da je vezi sa voćem i sortom - na koji način to funkcioniše, i čemu to polje pored: ID polja, polja NazivKlase i polja OznakaKlase?

Entitet DokumentStavka je u stvari mesoviti (asocijativni) entitet izmedju entiteta Dokument i PredmetPoslovanja, sto u stvari predstavlja vezu vise prema vise i prema IE notaciji koju ima ERwin CASE alat predstavljen je dvema crnim tackama (strana 56).



Polje KlasaVocaSort sam stavio da mozete rucno da definisete sortiranje n-torki u tabeli KlasaVoca. Samo je slucaj hteo da su tezinski sortirani ID brojevi.

Našao sam "Osobu, Jezik i Certifikat" (Veljović), kao asocijativni entitet. Jasno mi je značenje.
Tu se nalazi i odgovor na jedno od mojih ranijih pitanja: "U kakvoj su vezi PredmetPoslovanja i Voće i Ambalaža" - Podređeni entiteti. Ali kad smo već kod toga; Šta je odlučilo (na osnovu čega) da Voće i Ambalaža budu podređeni (ali posebni) entiteti Predmeta Poslovanja, a Roba i Avans budu sastavni deo Predmeta Poslovanja? Da li to što Voće i Ambalaža imaju neke svoje atribute (osobine), dok ih Roba i Avans ne poseduju - nego samo nazive? Mislim da sam nešto bitno naučio, ukoliko je ovo moje razmišljanje iole tačno.
Pozdrav!

Upravo tako, razmisljanje je tacno. To je kljucno za definisanje specijalizovanog entiteta od entiteta PredmetPoslovanja. Veza tipa generalizacije i specijalizacije je jako dobra, jer se model na taj nacin optimizuje. Intresantno je to sto Access ne poznaje model veze generalizacija i specijalizacija, a jako se lako implementira, sto sam prikazao u Vasem primeru.

Još samo jedno pitanje za danas. U tabeli PredmetPoslovanja indeksirana su tri polja: PredmetPoslovanjaID (PK), VrstaPredmetaPoslovanjaID (FK) i JedinicaMereID (FK); Da li je to označavanje jednoznačnosti jednog zapisa po više atributa (polja)? Šta znači: "XIF1PredmetPoslovanja" i "XIF2PredmetPoslovanja" u nazivu indeksa? Pozdrav!

PredmetPoslovanjaID (PK) je primarni kljuc i po toj definiciji je indeksiran sa osobinom (No Duplicates) sto znaci da ne dozvoljava da se pojave dve n-torke sa istim ID.

Polje NazivPredmetaPoslovanja po pravilima sistema oznacavanja je trebalo da bude indeksirano (No Duplicates), ali iz prakse izbegavam to da radim jer cesto se ima potreba da se prenose podaci iz neke vec postojece, a u njima se cesto svega nadje.

Polja VrstaPredmetaPoslovanjaID (FK) i JedinicaMereID (FK) su takodje indeksirana ali sa osobinom (Yes Duplicates sto znaci da dozvoljava pojavu duplikata), iz razloga sto su to preneseni kljucevi iz drugih tabela, te se prilikom postavljanja upita postize brzi odziv.



Odgovor je NE, a razlog sam vec naveo.

Poštujem pravilo da se kod polja, čiji je tip - Broj ili Valuta, u zadanoj vrednosti upiše "0", zbog mogućih kasnijih problema sa raznim Upitima, jer, ukoliko polje ostane nepopunjeno Access to može "protumačiti" kao Null i ne davati tačne rezultate po kolonama prilikom određenih operacija.
Da li je potrebno i neophodno kod polja, čiji je tip - Text upisivati "N/A" (Not Available)?

U paraksi uvek i samo uvek za atribute koji su novcani definisem vec u bazi default vrednost "0". Za ostale atribute veoma retko koristim bilo kakvu default vrednost na nivou tabele vec eventualno na nivou forme. Koncept "N/A" (Not Available) nema smisla po meni.

Završio sam rad na tabelama i relacijama. Bio bih Vam zahvalan kada bi pregledali i odobrili ovo što sam do sada uradio (po instrukcijama od "HladnjacaZE9").
U listama indeksa u tabeli DokumentStavke nije bilo naziva indeksa za polje PredmetPoslovanjaID (koje je spoljni ključ) - kad sam stavio "XIF1DokumentStavke" i sve osobine na "ne"; posle povezivanja tabela Access mi je vratio indeks polja PredmetPoslovanjjaID - bez naziva indeksa. Šta se desilo i da li sam to trebao da uradim?
Takođe sam nazive indeksa u tabeli Voce promenio u XIF!... i XIF2... Da li sam i to smeo da uradim, i da li, uopšte, od naziva indeksa nešto zavisi u daljem radu sa bazom?
Trebalo mi je dosta vremena da proniknem u novi model baze, i još nisam siguran da sam uspeo. Da li sam u pravu ako kažem da je tabela Dokument (ujedno takva ista i forma), po meni, na vrhu hijerarhijske lestvice unošenja poslovanja? Nije mi jasan način unošenja Predmeta poslovanja, a pre svega složenog naziva voća. Ostale nejasnoće kad krenem raditi forme.
Pozdrav.

Dok na dobijem mišljenje, promeniću sve nazive tabela. Obrisaću "t_", koje sam stavljao kao sastavni deo imena. Kasnije će mi to mnogo smetati prilikom korišćenja nekih gotovih rašenja iz "...ZE9". A to je bio jedan i od prvih Vaših saveta - da se ne moraju stavljati nikakvi prefiksi kod naziva Access objekata.

I relacije između tabela Voce i Ambalaza i PredmetPoslovanja "kreću" od PredmetPoslovanjaID, jer je tabela PredmetPoslovanja tabela-roditelj.

Kada ovo preporucujem ogradjujem se jer je to moje licno misljenje. Smatram da je samo gubljenje vremena i vise puta sam rekao da je "UBIJANJE VOLA ZA KILO MESA"

A sto se prethodnog posta tice, preporucujem da ostavite da baza sama dodeli svoje nazive indeksa, nije potrebno lomiti glavu oko toga. Ja kad amodeliram baze koristim nezavisan CASE alat ERwin, koji isto tako sam stvari definise.



Vidite modeliranje baza je slozen proces i smatra se da ne moze kvalitetno taj posao da radi neko ko ima ispod 35 godina starosti i sa tim godinama dovoljno veliko iskustvo u programiranju. U godinama u kojim sam, sve priznajem... A kada sam pocinjao jos davne 1975 trebalo mi je da prodje 11 godina da shvatim i jos pored toga priznam da Ja gresim. :-)



Da u pravu ste dokument je osnov informacionih sistema (mnogi povezuju pojam informacioni sistem sa racunarom), a smatra se da on postoji od prvog pisma. Primena racunara a samim tim i aplikativnog softvera sa bazama podataka upravo predstavlja preslikavanje elemenata skupa iz informacionog sistema, a informacioni sistem predstavlja preslikavanje elemenata skupa realnog sistema. Primena dokumeta kao objekta najvernije preslikavanje, a od kvaliteta preslikavanja zavisi kvalitet i funkcionalnost primene racunara. U vasem primeru nisam radio specijalizaciju entiteta Dokument po diskriminatoru VrstaDokumentaID, koji predstavlja operator "ILI". U mojoj praksi pokazalo se da ima potrebe modelirati generalizovan entitet Dokument i njegove specijalizante, a to zavisi od obima preslikavanja ili kako kaze IDEF0 metodologija od granice sitema koji se posmatra. Daklem Dokument je jedan od vaznih objekata i njegova primena predstavlja koncept.



Predmet poslovanja je drugi vazan koncept u sistemu. On predstvalja okosnicu sistema oznacavanja cinilaca poslovanja. o tome sam vec pisao da se ne ponavljam. Kao i Dokument i PredmetPoslovanja putem diskriminatora VrstaPredmetaPoslovanjaID moze biti specijalizovan, opet u zavisnosti od granice sistema.

Ako ništa drugo nije na mojoj strani u vezi Access-a i modeliranja, bar ispunjavam jedan od uslova - imam malo više od 35 godina starosti, a i nameran sam u zanatu "SUBP" dogurati do izvesnog nivoa znanja i veštine.
Napokon sam "isprintao" i ukoričio IS od Veljovića, "bacio" se na teoriju i upravo bistrim IDEFO metodologiju, granice i stablo sistema, itd.
U bazi trenutno sam u izradi obrazaca, pratim Vas, a pitanja ću objediniti kad ih se nakupi nekoliko. Za sada (možda se ponavljam) i dalje mi je najveća nepoznanica sistem unošenja PredmetaPoslovanja (za naziv voća). Niste valjda svih 480 vrsta voća uneli ručno. Ja bih to prepustio korisniku aplikacije da sam unese one vrste i sorte sa klasom sa kojima trenutno radi. Nema svaka vrsta voća svaku vrstu sorte (koja se nalazi u tabeli SorteVoca). Zašto u obrazac PredmetPoslovanja ne mogu uneti novi zapis? Mislim da u formi PredmetPoslovanjaLista ne moraju se navoditi sorta i klasa (u nazivu) kad ova dva podatka se dobijaju iz ComboBox-ova; I zašto u ovoj formi nema ostalih predmeta poslovanja - nego samo voća? U formi Dokument ne mogu otvoriti VrstuDokumenta - zašto? Javlja mi: "Run-time error 94" ("Vrsta = Me.OpenArgs" linija u VBA mu nije jasna). Molim Vas da ovo shvatite kao nejasnoće i kao moja viđenja - nikako drugačije!
Pozdrav.

Novi predmet poslovanja se unosi preko forme VrstaPredmetaPoslovanjaLista gde na samom ulazu odredite kojoj vrsti pripada i klikom na dugme ... otvara se forma koja je karakteristična za tu vrstu.



Forma Dokument se otvara iz forme VrstaDokumentaLista po istom principu kao i predmet poslovanja.
Ako je otvorite direktno daje grešku koju ste naveli iz razloga što nedostaje argument koji se prosleđuje prilikom otvaranja forme Dokument iz forme VrstaDokumentaLista.

Kada se otvori forma Dokument ona preuzima argument iz prethodne forme i u ovom izrazu Vrsta = Me.OpenArgs nadalje se koristi.

Poštovanje.
Sve sam malo ostavio po strani dok ne "savladam" Veljovića. Došao sam do tačke kada mogu da čitam i analiziram ER model "Hladnjače" i u tom duhu dva učenička viđenja:
1. Zašto Entitet VtstaPredmetaPoslovanja nije povezan sa entitetom PredmetPoslovanja identifikujućom ili (što je možda realnije) obaveznom neidentifikujućom vezom? Po mom mišljenju svakom PredmetuPoslovanja se mora pridodati po jedno obeležje (FK) od strane VrstaPredmetaPoslovanja, znači - kardinalnost od VrstaPredmetaPoslovanja ka PredmetPoslovanja ne može biti Null.
2. Mogli smo (tj. Vi) i entitetu Partner pridodati (ili se kaže povezati ga) sa dva entiteta kategorija (potkaegorija) - fizičko lice i pravno lice.
Kod baze sam još uvek kod formi. Možda izgleda da sam jako spor, ali stvarno mi treba vremena da sve što pročitam ili uradim - ujedno i shvatim i povežem.
Pozdrav!

Zakljucak je cista 10-ka. Veza mora da bude obavezna neidentifikujuca. Zasto kardinalnost od VrstaPredmetaPoslovanja ka PredmetPoslovanja ne stavljam da je Null? Cisto radi toga ako imam potrebe da prenosim podatke da se ne ukopam zatezanjem stvari.



Slazem se i cesto sam stavljao primer na ES.

http://www.elitesecurity.org/t...ristiti-specijalizaciju-ili-ne

A sad malo prakse.
Pola dana "stojim" kod obrasca Partner, mučim se i nikako da pogodim kako da postavim CheckBox (2 komada) kod podatka UgovorDaNe, a u slučaju kada je taj tip podatka naveden kao broj (bajt), sa mogućim vrednostima 1 i 0. U prethodnoj verziji "Hladnjače" sam to odradio bez muke, a sad, niti mogu da setim načina, niti mogu da pronađem "pomoć" odakle sam to uradio. Buni me to što je u Vašem primeru kod te kontrole grupisano ukupno 6 polja (dva CheckBox-a, dva polja za tekst,..). Ne mogu da dođem do toga da mi za CheckBox-ove List svojstava ponudi opciju: Vrednost mogućnosti (u kartici - Podaci).

Za polje UgovorDaNe nisam koristio CheckBox tip objekta vec Option Group koji ima samo 2 opcije.

E sada sam valjda blokirao dibidus! Ja ovo ne mogu da pronađem i uradim (a bilo bi dobro), pa sam privremeno za polje UgovorDaNe postavio tip Da - Ne. Od jutros ne mogu ni u jednu formu da postavim kontrolu "Dugme" (četvrta u gornjem redu kontrola - kod mene - između Natpisa i TabControl) kojom pozivan druge obrasce ili radim sa zapisima itd; To je tip kontrole kojom sam postavljao akcije za rad sa zapisima (dodaj, spremi, sačuvaj i zatvori). Koristim MS Access 2010 (hrvatski prevod). Doduše, juče sam nešto "čačkao" po opcijama, ali se ne sećam da sam nešto bitno promenio u postavkama.
A sad nešto konkretnije. Zašto je u tabeli, pa i u obrascu, OtkupnoMesto - stavka PartnerID? U tom slučaju se za jedno OtkupnoMesto vezuje samo jedan Partner, ili treba onoliko puta uneti isto OtkupnoMesto koliko je Partnera vezano za njega. Po mom mišljenju u tabeli (samim tim i u obrascu) Partner potrebna je stavka OtkupnoMestoID, čime svakog Partnera, u startu, vezujemo za odgovarajuće OtkupnoMesto.
Pozdrav!

"Sredio" sam kontrolu za pozivanje akcija nad zapisima, drugim formama i ostalim, odobravajući čarobnjaka za "dugme naredbe".

U Entitetu OtkupnoMesto stoji atribut PartnerID (FK) koji ukazuje ko je Vlasnik tog otkupnog mesta. Otkupno mesto u stvari predstavlja lokaciju gde se pojavljuje predmet poslovanja. U projektu SojaProtein imao sam sličan slučaj gde je soja mogla biti locirana na nekih 300-400 lokacija u bivšoj (SRJ) i inostranstvu, od kojih je bila recimo lokacija "Kod gazda Jove iza ambara" :-).

Sve ostale potrebe vezivanja partnera sa otkupnim mestom mogu biti u domenu mešovite veze, što u Vašem slučaju ne vidim da je potrebno.



Lično ovu rabotu smatram ubijanje vola za kilo mesa, budući da su sistemski ugrađene kao gotovo rešenje.

Jasno mi je, veza: Lokacija - Vlasnik. Ja sam bio mišljenja da se tu radi o podacima o svim partnerima.
Hvala!

E sad sam došao do višeg nivoa, gde mi je stvarno pomoć neophodna, i to pomoć sa razumevanjem mog početničkog neznanja. Kod "Veljovića" sam lagano u poslovnim pravilima, odnosno kod detaljne izrade, uloge i opisa atributa, kod kardinalnosti, itd.
A sad Baza!
Uradio sam i Upite, izmenivši ih utoliko koliko su kod mene tabele malo drugačije nego kod Vas. To se pre svega odnosi na drugačiji raspored atributa. Uradio sam i osnovne obrasce. Ostali su mi najteži obrasci tipa: PredmetPoslovanja i Dokument, za koje mi treba velika pomoć i u shvatanju značenja naredbi (kontrola) i njihovoj nameni i njihovom kreiranju. Nikako sve odjednom - nema ni svrhe, a verovatno Vam nisam ni ja "jedini na glavi". Mislim da mi je po redu izrade i hijerarhiji na redu obrazac "VrstaPredmetaPoslovanjaLista", zatim "PredmetPoslovanjaLista" i "PredmetPoslovanja", itd. Mada, vidim da su svi ovi obrasci i međusobno povezani, kao i dodatni (PredmetPoslovanjaListaVoce i PredmetPoslovanjaListaAmbalaza). Isto tako, vidim da se, čini mi se, PredmetPoslovanja ne može popunjavati direktno nego se otvara iz... (nije mi baš jasno odakle). Znači potrebno mi je i malo (ustvari dosta) objasniti model, pre svega obrazaca, po dubini i po širini - gde se šta popunjava i s kojom svrhom, šta je sa čim povezano, kako se dolazi do određenih podataka za određene kontrole, kako se kreira... Po mom početničkom zaključku naredna forma je PredmetPoslovanja, ali ja u toj formi niti mogu dodati sledeći ID, ni promeniti Vrstu, ni dodati novi PredmetP - jedino mogu promeniti naziv postojećeg PredmetaP... - ali sigurno nisam u pravu. Izraz koji koristite, recimo kod, PredmetPoslovanjaLista
"=Nz(DMax("[PredmetPoslovanjaID]";"PredmetPoslovanja");0)+1" mi je stran, mada znam teoretski šta znači i Nz i DMax. Kako ste u ovoj kontroli zapravo nalaze tri kontole: i običan tekst i navedeni izraz i VrstaPredmetaPoslovanjaID?
Mislim da sam "osnovne osnove" IS i BazaPodataka pregurao i hteo bih dalje.
Pozdrav. Hvala.

Tako je dobro ste uocili. U svakom polsovanju pitanje svih pitanja je sta je predmet vaseg poslovanja. Kada ga odredite treba ga jasno definisati primenom standarda. Nazalost mnogi to ne cine nego pisu sve i svasta. Identifikacija predmeta poslovanja ide putem klasifikacije. U Vasem primeru modela nisam isao toliko daleko jer bih Vas ionako previse zatrpao. Klasifikaciju sam uprostio i sveo na VrstuPredmetaPoslovanja. Znaci svaki predmet poslovanja pripada nekoj vrsti (klasi). Ako je to tako da bi se obezbedilo to pravilo zbog toga sam vam aplicirao da mozete novi predmet poslovanja definisati preko vrste. Znaci otvaranjem forme VrstaPredmetaPoslovanjaLista vi se odredite kojij vrsti pripada taj novi predmet polsovanja i klikom na ... otvara se forma koja odgovara toj vrsti. Pojedine vrste predmeta poslovanja su diskriminatori koji definisu specijalizovanie entitete sa dodatnim osobinama i u zavisnosti od vrste napravljene su forme koje su prilagodjene tim specijalizantima, tako da se podaci u jednom prolazu unose u dve tabele odjednom (svojevremeno kada sam radio jedan model za osnovna sredstva imao sam 17 specijalizacija i to do 4 nivoa, sto znaci da je jedan predmet poslovanja se unosio u 4 tabele odjednom). Sta se time postize? Pa prilikom ulaza tj unosa novog predmeta poslovanja vi u startu definisete kojoj klasi vrsti pripada i podatke u zavisnosti od specijalizacije rasporedjujete u te tabele. Na ovaj nacin se mogu lako dobijati informacije preko svega ili preko nekog specijalizanta.
Sledeca osobina predmeta poslovanja je standardizovan naziv koji sadrzi imenicu i od 2-3 glavne karakteristike "Breskva Ajdared Extra klasa" dok ovaj primer nije dobar "Veštačko đubrivo - KAN" trebalo bi da je "Đubrivo veštačko KAN".
Sledeća osobina je interna šifra, Stara šifra ako je bila ranije, jedinica mere,...


Pomenuti izraz nije kontrola već u sebi sadrži dve funkcije (Nz i DMax) Ovim izrazom se dobija efekat Autonumber-a, koji se koristi da se dodeli novi PredmetPoslovanjaID u tabeli PredmetPoslovanja.

Da se nadovežem na @Zorana i pojasnim što funkcija radi

DMax("[PredmetPoslovanjaID]";"PredmetPoslovanja") + 1

ova funkcija bi vratila iz tablice PredmetPoslovanja najveći broj PredmetPoslovanjaID i uvećao ga za jedan

sve bi to radilo kad ima podataka, ali kad još nije upisan nijedan podatak u tablicu , funkcija vrati NULL i javi ti grešku

zato stavljamo još i funkciju NZ , koja u slučaju da se pojavi NULL podatak ili ako je prazno "" stavi 0 u podatak ili ono što mi sami odredimo

"=Nz(DMax("[PredmetPoslovanjaID]";"PredmetPoslovanja");0)+1"

Hvala ljudi!

Kao i svakom "dobrom" učeniku trebalo mi je vremena da se "setim" da i od upita mogu kreirati obrasce, što je u slučaju "Hladnjace" uglavnom korišćeno. Moram nanovo uraditi sve Upite. Samo jedno pitanje. Kada kažete "...tako da se podaci u jednom prolazu unose u dve tabele odjednom...", da li to da razumem da se podaci unose i čuvaju i u samoj (određenoj) Tabeli i u pripadajućoj tabeli (određenog) Upita?
Potkrao Vam se Upit koji, čini mi se, ne pripada "Hladnjaci" - QOsobaSertifikatZnanje.
Pozdrav!

Evo na primeru Ambalaze...

Entitet Ambalaza je specijalizovani entitet od PredmetPoslovanja diskriminacija ide putem VrstAPredmetaPolsovanjaID kaoo sto se vidi na sledecoj slici.


Daklem ako je u tabeli PredmetPoslovanja, PredmetposlovanjaID=481 i odnosi se na "Jabučar" isti ID se nalazi i u tabeli Ambalaza
Ako u Query-ju QAmbalaza uvezemo obe tabele dobicemo kao na slici n-torke koje su Ambalaza sa svim pripadajucim atributima i on sluzi kao record set u formi PredmetPoslovanjaListaAmbalaza. Sto znaci da ako zelite da uneste novu ambalazu treba da pozovete formu VrstaPredmetaPoslovanjaLista i na n-torku koja predstavlja Ambalazu kliknite na ... tada ce vam se otvoriti foma PredmetPoslovanjaListaAmbalaza i odete na novi rekord.

A sto se tice zalutalog query-ja QOsobaSertifikatZnanje izvinjavam uvukao sam ga da ne kucam. Treba ga obrisati.

Poštovanje!
Query-i su gotovi, a problemi - nekoliko:
- Kod Upita QPartner pretposlednja kolona "Ambalaza" daje - #Pogreška!?
- Upit QOtkupnoMesto mi ne vraća nijedan podatak!
- Kada hoću da otvorim Upit QPartnerAmbalazaKonkatenacija - ne mogu; Access ne može prepoznati (definisati) funkciju: ConcatRelated u izrazu. Isti ovakav Vaš Upit se otvara bez problema.
- U Upitu QSorteVoca mi, takođe, "BrojSorti" daje - #Pogreška!
- U Upitu QVrstaDokumentaPartner, isto daje, #Pogreška (kod broja vrsti) i traži unos parametara za "PartnerID" prilikom otvaranja.
Šaljem ono što uradih do sada.
Pozdrav.

Niste preuzeli Modul Konkatenacija iz mog primera.

- Upit QOtkupnoMesto mi ne vraća nijedan podatak!

Pogledajte taj upit u mom primeru bice Vam sve jasno

- U Upitu QSorteVoca mi, takođe, "BrojSorti" daje - #Pogreška!

kod mene ne daje gresku ?!?!? doduse u tabeli Voce nemate nijedan podatak pa meni sve daje vrednost 0

- U Upitu QVrstaDokumentaPartner, isto daje, #Pogreška (kod broja vrsti) i traži unos parametara za "PartnerID" prilikom otvaranja.

Moja greska treba da stoji u poslednjoj koloni:

BrojVrsti: DCount("[DokumentID]","Dokument","VrstaDokumentaID=" & [VrstaDokumentaID])

OK!
Hvala.

Za Modul neću ni da pitam ništa, to ćemo kasnije. To je već mnogo viši nivo rada. QPartnerAmbalazaKonkatenacija je sada u redu.
QPartner - sređen. QSorteVoca - sređen. QPartnerAmbalaza - sređen. Ove Upite nisam ni "dirao", mislim da su i oni profunkcionisali pomoću Modula Konkatenacija.
Kod QVrstaDokumentaPartner i novog izraz - BrojVrsti: DCount("[DokumentID]","Dokument","VrstaDokumentaID=" & [VrstaDokumentaID]) - umesto zareza treba staviti operand - tačka i zarez (polako primenjujem naučeno).
Kod QOtkupnoMesto sam raskinuo vezu između Tabele "Partner" i Tabela "Mesto" i "Ulica" i promenio osobine spojeva prema Tabeli "OtkupnoMesto" u redni broj 3, odnosno: "Uvrsti SVE zapise iz tabele OtkupnoMesto i samo one zapise iz tabele - te i te - kod kojih su spojena polja jednaka". Dok nisam uklonio veze iz tabela Ulica i Mesto prema tabeli Partner, Access mi je javljao da SQL naredbu ne može da izvede zbog postojanja višeznačnih spojeva. Ovde bih molio za objašnjenje zašto Upit nije "radio" i šta je promenjeno te sada funkcioniše.
Sada su i Upiti urađeni, prelazim na Obrasce; Samo da Vas pitam: Da li sam u pravu ako mislim da su svi (ili barem - skoro svi) Obrasci urađeni nad Upitima (ili da kažem - iz Upita)?
Pozdrav.

Kada se gradi neki upit, kao npr. QOtkupnoMesto onda se postavlja pitanje šta želite da dobijete iz tog upita i odakle te informacije uzimate tj iz kojih tabela. Pošto je osnov upita nad tabelom OtkupnoMesto i da bi se dobila informacija o Partneru jer je tabela OtkupnoMesto vezana stranim ključem sa tabelom Partner morali ste u upit povući i Partner-a, ali nedaj vraže i tabela OtkupnoMesto i tabela Partner su vezani za tabele koje određuju njihovu lokaciju. Ako se uvuku tabele Mesto i Ulica Access po automatizmu povalči i njihove veze sa tabelama koje su uvučene. Budući da je tako upit je doveden u iracionalno stanje, stanje neodređenosti. Da ste kucali Select naredbu koja je osnov svakog upitnog jezika ne bi sebe doveli u ovo stanje. Zato se veze između tabele Partner i tabela Mesto i Ulica moraju ukloniti iz upita, da bi se pogled mogao odrediti. Korišćenje grafičkog formiranja upita ima svojih prednosti ali je preduslov toga da dobro znate SQL upitni jezik. Pok. prof. dr Branislav Lazarević je znao da kaže studentima "vaš upit kolega zapao u je informatičku šizofreniju".

A za drugo pitanje odgovor je: Da tako je

Počeo sam da sanjam Baze - objekte. atribute, veze, konkatenaciju, diskriminatore, IDEF1X, funkcije (Nz, DMax, DSum...), Predmete poslovanja, nezavisne entitete, rekurzivne veze,...
1. Uradio sam Obrazac PredmetPoslovanja. Pitanje:
- Na šta upućuje i zašto mora biti tu postavljena (u tom obrascu) kontrola VoceID? Ona se kod Vas "ne vidi", a nije
onemogućena. I zašto "=7" kao zadana vrednost (i opet - ne vidi se u obrascu). Ja sam tu kontrolu preuzeo iz tabele
Voce (VoceID), Jedino što mi je jasno (čini mi se) je da VoceID u stvari je preneseni ključ iz nadređene tabele
PredmetPoslovanja, jer je čitava tabela Voce - tabela kategorije.
2. Obrazac VrstaPredmetaPoslovanjaLista sam uradio.
- Pitanje je: Kako postaviti kontrole u stubastom obrascu, za otvaranje (više vrsti) obrazaca kategorija - Voće, Ambalaža, Roba, Novac i Usluge, po redovima? Kada sam ja kreirao kontrolu, za recimo PredmetPoslovanjaVoce - meni obrazac u svakom narednom redu formira tu istu kontrolu, a trebaju mi kontrole za druge kategorije Predmeta poslovanja?
3. Obrasce PredmetPoslovanja(Kategorije) sam uradio (ili ću uraditi) iz Upita: QVoce, QAmbalaza, QRoba, QNovac i QUsluga. Da li je to u redu? Ako jeste - onda se pitanja ponavljaju za svih pet obrazaca.
- Da li su to sve, ustvari, i pojedinačno kreirani obrasci, jer kod Vas, recimo, ne vidim u spiku objekata PredmetPoslovanja za novac, robu i usluge, mada se do njih "dolazi" iz obrasca VrstaPredmetaPoslovanjaLista?
- U kontroli Naziv PredmetaPoslovanja su umetnuti:
a) Funkcija "=Nz(DMax("[PredmetPoslovanjaID]";"PredmetPoslovanja");0)+1" i
kontrola za VrstuPredmetaPoslovanjaID, koji se vide samo u prikazu dizajna.
b) Unutar kontrole Šifra je umetnuta Kontrola VoceID, Koja se, isto tako, vidi samo u dizajn pogledu.
I Vi i Trtko ste mi objasnili funkciju "Nz(DMax..." - jasna mi je, ali mi nije jasno, recimo, šta konkretno "radi" i šta bi bilo da nije na tom mestu. Kako ove kontrole i funkcije da kreiram da se i kod mene ne pojavljuju u prikazu obrasca?
Sva pitanja su u vezi večeg broja obrazaca (Vrste Predmeta poslovanja) pa čak i i u obrascima tipa Dokument, tako da ako ovo "preguram" mogu reći da je vredelo truda, razumevanja i nerava - mog, a i vašeg (pre svega Zoranovog, a naravno, i Trtkovog i Getsbijevog).
Pozdrav!

Na osnovu ove konstatacije sve ukazuje da ste na dobrom putu. :-)


Ovo je moj cisti previd, izvinjavam se. :-(


Prakticno preko vrste predmeta poslovanja vrsi se diskriminacija prema svim definisanim specijalizantima predmeta poslovanja.
Da vidimo sta prakticno znaci generalizacija i psecijalizacija? Ako ste prethodno konstatovali da je vas predmet poslovanja odredjene vrste to znaci da ste se odredili koji je diskriminator u pitanju i ako je u modelu po toj diskriminaciji odredjen specijalizovani entitet onda se pristupa otvaranju forme koja za Record source ima Query koji povezuje generalizovani entitet sa konkretnim specijalizovanim entitetom. To znaci da se u generalizovanom entitetu prilikom insertovanja n-torke pojavljuje naredni ID i taj isti ID se insertuje u vec unapred predodredjen specijalizovani entitet.

E sada tu nastupa problem, a to je raskorak koji postoji izmedju relacionih modela (RDMS) i teorije realacionog modeliranja. Ovde moram da se unapred ogradim iz tog razloga sto moja znanja nisu toliko velika, ali zasigurno znam da MS Access i MS SQL Server ne podrzavaju tip veze generalizacije i specijalizacije te se u realizaciji prilikom apliciranja pristupa dovijanju da se simulira takav tip veze. U prethodnom primeru sam dao jedno prostije resenje koje ima i malu manu a to je da zahteva insertovanje u formi barem jednog polja koje je deo specijalizanta. U danasnjem prilogu imate drugi mnogo bolji nacin resenja forme koja koristi specijalizanta gde se insertovanje u specijalizovani entitet resava pokretanjem adekvatnog Query-ja (QAmbalazaIDDodaj i QVoceIDDodaj).


Ako generalizovani entitet nema potrebu za specijalizaciojom po odredjenoj vrsti predmeta poslovanja, tada Vrsta predmeta poslovanja kao diskriminator moze odrediti samo jednu formu filtriranu po tom diskriminatoru i tada je dovoljno da VrstaPredmetaPoslovanjaID bude default vrednost u narednoj otvorenoj formi a to je forma PredmetPoslovanjaLista.

_{[Ovu poruku je menjao Zoran.Eremija dana 13.09.2011. u 00:29 GMT+1]}

Poštovanje i hvala za podršku.
Mala digresija; Beše nekad, nečiji, slogan: "Srbija na dobrom putu" - i vidi gde smo sad!
Hvala za potpuni i konkretan odgovor. Jasno mi je da je generalizovani entitet PredmetPoslovanja i da se diskriminacija vrši preko VrstePredmetaPoslovanja na specijalizovane entitete: Voce, Ambalaza, Novac, Usluge i Roba; Ali ja i dalje ne mogu (ne znam) kako da postavim i namestim da mi kontrole (iz forme VrstaPredmetaPoslovanja) imaju određeni Record Source koji će otvarati samo određene n-torke, odnosno određene forme Query-ja određenih kategorija (nadam se da u ovoj rečenici nigde nisam napravio grešku i da je jasna i tačna). Konkretno (opet ću dobiti grdnju od Getsbija!), treba mi "da vidim" na primeru kako se to radi. Znači, ja bih ostao na prethodnom primeru Vaše baze (o akcijskim Upitima ću kasnije). Znači počeo bih unos PredmetaPoslovanja, ali preko Formi (Query-ja) kategorija, i još jednom - ali, prvo ih moram kreirati. Za početak, nikao neđu imati blizu 500 PredmetaP.
Sad nešto gledam i razmišljam i o ovome: prema diskriminatoru VrstaPredmetaPoslovanja ima pet specijalizanata PredmetaPoslovanja (Voće, Ambalaža, Roba, Usluge i Novac - a može ih biti i još), a samo dva entiteta kategorije. Da li to znači da entitete imaju samo kategorije koje imaju i neke određene, samo svoje, atribute i da u VrstuPredmetaPoslovanja mogu dodati još neku kategoriju, a da ona ne mora imati svoj poseban entitet kategorije (ukoliko nema potreba za to)? To su sad već granice sistema!?

Odgovor na ovo pitanje imate u kodu koji se nalazi na dugmetu ... na formi VrstaPredmetaPoslovanjaLista i to na Event On Click.


Tako je dobro ste uocili. Sve zavisi od intresa posmatranja. Od toga zavisi i koje atribute cete identifikovati kao generalizovane a koje kao specijalizovane. U praksi sam znao da se ne drzim strogo pravila vec sam znao i da popustim iz nekih opravdanih razloga.
Veza tipa generalizacija i specijalizacija je jako dobra u slucaju kada imate veliki broj podataka, a imate potrebu da koristite samo pojedine n-torke s jedne strane, a pak sa druge strane trebaju vam svi. Najbolji primer toga je recimo primer dokumenta ZahtevZaNabavku. U nekom sistemu svi pisu taj dokument i on po prirodi moze da ima svoje stavke u koje se upisuje predmet poslovanja. Dok recimo neki realni sistem kao vrstu predmeta poslovanja ima vozilo i imate dokument NalogVozila i tada za taj dokument cete vezati samo specijalizovani entitet Vozilo, gde recimo od 40000 razlicith predmeta poslovanja moze biti samo 10-tak koji su Vozilo. Na ovaj nacin se vrsi optimizacija modela i umnogome pojednostavljuje rad a samim tim i kasnije izvestavanje.

Napokon sam uhvatio korak, proniknuo sam u rešenja svega oko čega sam se "patio" do danas.
Inače, kod sam ja upotrebio ranije, ali nije pomoglo, mislio sam... Na kraju je bila sitnica u pitanju (hm, da li je u Bazama i Access-u bilo šta sitnica). Vi u kodu za naziv kontrole koristite ime "Detaljno", a moje dugme "..." se zvalo drugačije. Idem dalje, samo jedno pitanje:
- Forme za PredmetPoslovanja za novac, robu i uslugu kod Vas u spisku objekata ne vidim (mada sam siguran da postoje), a mislim da se moraju formirati. Da li sam u pravu ili je nešto drugo u pitanju?
Pozdrav!

Ako neku vrstu predmeta poslovanja nije potrebno posebno opisati nekim specijalizovanim entitetom, a samim tim i njemu pripadajucim atributima, tada je dovoljno imati jednu formu kao u Vasem slucaju PredmetPoslovanjaLista, koja se poziva u svim takvim slucajevima sto se moze videti iz koda koji stoji ispod ... (Detaljno) u formi VrstaPredmetaPoslovanjaLista.

Samo da se jednom javim bez pitanja. Pratim Vas, i odjednom kao da mi je "uključena" i sledeća lampica u vezi rada sa Bazama. Sada već mogu i sam sebe da pratim - šta radim i zbog čega to radim i sa čim je u vezi to što radim. Imam viziju nivoa rada sa Bazama (po složenosti razumevanja i rada): 1. Access; 2. SQL; 3. Modelovanje.
Naravno, pre svega Vama dugujem veliko hvala! Počinjem završnu fazu obrazaca (Dokumente). Pozdrav.

Samo mala korekcija u redosledu koraka. O tome sam govorio i imate prezentaciju na sledecoj adresi http://www.elitesecurity.org/t166884-0#2720176.

Srecno!

Pogledao sam prezentaciju "Primena računara ES" i jasno mi je daje to u osnovi mini priručnik ponašanja ka kvalitenom modelovanju i kvalitetnoj izradi baze podataka. I sve to mi je u glavi "još od" Veljovića i IS.
Nadam se da je Vaše - srećno, samo pozdrav, a ne napuštanje ove stranice.
Pratim model baze "...ZE20110820". U obrascu VrstaDokumentaLista postoji tekstni okvir - "Slobodno", čiji je naziv IDPartner. Pošto po osobinama tog okvira ništa ne mogu zaključiti, a gledajući VBA kod tog obrasca (naravno, jer još nisam u fazi isčitavanja) rekao bih da ta kontrola (okvir) tu i treba da bude, samo bih pitao: Odakle je kreirana i kakvu ulogu ima? Ili grešim!?
Pozdrav.

Treba da stoji i ima jednu intresantnu ulogu. Radi se o klasicnoj programerskoj prevari. :-)
A cemu sluzi ostavljam Vama da otkrijete. :-)

Blago meni. Samo sam se osmehnuo i rekao - Hvala! Ajde da vidimo, dajte mi malo vremena.

Toliko me je okupirao zadatak "prevare" da sam uzeo iz police i "VB 6.0 Bibliju" i rešio da u Bazama "idem do kraja".
Buni me malo to što kažete da prozor (ili je kontrola - mada ne verujem) "IDPartner" potrebna u obrascu. Čak se i u kodu u jednoj proceduri (nadam se da je formulacija ispravna) navodi: iPartner = Nz(Me.IDPartner, 0). I vidim da je u vezi sa "iPartner" koji je ceo broj (Integer). I opet izraz sa Nz; To znam. Treba da vrati nulu, ako je podatak Null. Međutim, ono što me najviše muči je to što nigde u bazi "Hladnjača" nema niti jednog objekta pod nazivom - IDPartner. Ono što bi moglo da bude slično, ali nikako isto, je - PartnerID. Ako je rešenje drugačije, treba ga isčitati iz koda. U tom slučaju će mi trebati još neko vreme.
Pozdrav!

Kod obrazaca sam tipa - Dokument. Još uvek kreiram "DokumentStavka", mislim da je on po hijerarhiji "najniži", odnosno da je on u jezgru svih ostalih obrazaca tog tipa. pokušavam da umetnem nekoliko novih kontrola, ali ne uspevam. Nisam siguran da li treba da ih nekako iskombinujem i postavim i u QDokumentStavka ili je dovoljno "samo" ih pridodati obrascu Dok..Stavka. Radi se o sledećim kontrolama (koje su jako važne kod prjemnica i otpremnica - dok će u ostalim slučajevima one imati vrednost nula, a imaće i važnu ulogu kod izveštaja): TARA TEŽINA, zatim TEŽINA PALETE na kojima su poređane GAJBE (ambalaža) u kojima se nalazi voće i BROJ AMBALAŽE (gajbi). Tako da se NETO težina (odnosno - količina, kako stoji koda Vas u Query i u Obrascu) dobija kada se od TARA težine oduzme sve kasnije nabrojano. Ovo je sve situacija merenja prilikom Prijema robe ili Prodaje te robe. Ukoliko ovim zahtevom dopune kršim Granice Sistema - radićemo bez toga.
I druga stvar za koje bih kraće objašnjenje je: Zašto je u QDokumentStavka kod kontrole PredmetaPoslovanjaID, kod Upita za tu kontrolu, a kod polja VrstaPredmetaPoslovanjaID dat kriterijum "2" što je samo Ambalaža. Kad u tu formu treba upsivati razne PredmeteP... a ne samo ambalažu. Naravno detaljnim pregledom Baze sam video da se i stvarno mogu upisati razni PredmetiPoslovanja, ali zašto onda kriterijum?
Poštovanje!

Izvinjavam se zaboravio sam da obrisem taj uslov jer on se uopste i ne tretira, kao sto ste i zapazili uslov se definise na dogadjaj OnCurrent. :-( Zakljucak je da stvarno sitno seckate...:-)

A u vezi prvog dela pitanja granicu sistema Vi definisete, tj potreba da se realno preslika sistem. Ako to zahteva onda cete svakako dodati dodatne opsine atribute i kasnije koristiti. Mozete kao i sa predmetima poslovanja da kontrolisete i koji ce se atributi pojaviti u zavisnosti od Vrste dokumenta. Mozda je najlakse da napravite onoliko formi DokumentStavka koliko se po vrsti razlikuju atributi koje koriste i prilikom izbora vrste dokumenta kontrolisete koja ce se otvoriti.
Zakljucak: sigurno ne krsite granicu sistema jer je Vi postavljate. Cesto sam u praksi imao slucaj da sam samog sebe korigovao i ispravljao.

Ps: Ne treba bezati od 0 kao vrednost, ako ce vam tako biti lakse.

Pozdrav.
1. Niste mi odgovorili na moje pisanije u vezi "IDPartner" iz čega zaključujem da nisam ni blizu rešenja.
2. ":-( Zakljucak je da stvarno sitno seckate...:-)". U svakom slučaju ste u pravu, bilo da je pozitivna ili negativna kritika.
3. Što se tiče dodataka u vezi DokumentLista, svakako ih trebam ubaciti zbog kasnijih Izvešaja u vezi stanja (pre svega voća) unutar hladnjače, kao i kada se ono proda - prema stanju i broju ambalaže i Partnera čija je roba. Da li mi je tu neizbežno dopuniti Upit DokumentStavka i još napraviti posebne Upite za Prijemnicu i Otpremnicu (koji bi ustvari bili isti - jedan), dok QDokumentStavka za zaduženje ambalaže, robe i avansa može ostati isti ovaj kakav je sad. Bojim se da ću poremetiti niz drugih stvari, pre svega podatke za - PartnerLista. Da li da mi vodilja za kreiranje Query-ja Prijemnica-Otpremnica bude Query QVoce, a zatim da napravim formu kao što je PredmetPoslovanjaListaVoce? Znam da bi Vam brže bilo da to sami uradite, ali bih zamolio da, ako imate strpljenja, da to pokušam ja uraditi - uz Vašu asistenciju.
4. Zanima me kako ste izvršili dobijanje složenog naziva voća u nazivu Predmeta poslovanja, kad nigde ne vidim ni "Trim" ni kontakenaciju za ta polja?
Poštovanje.

Dobro pogledajte primer.


Odgovor je Da.

Odogovor imate u primeru u prilogu.

Prvo veliko hvala za dalju podršku mojim namerama približavanju Bazama i Access-u. Nemam reči za Vaše strpljenje i dobru volju. Suvišno je i spominjati znanja i iskustva. Cilj i jeste približiti se bar malo vama "odabranima" majstorima zanata.
- "IDPartner"; Jedino što sam zaključio u vezi ovog okvira je da je uvezi sa kontrolama koje pokreću različite vraste dokumenata i da ne postoji Izvor kontrole za njega!? Na šta da obratim pažnju kada kažete da dobro pogledam primer?
- "Složeni naziv voća"; Primer mi je više nego jasan. Ali u Bazi koju radim (tj. mi) ja nigde ne vidim dve stvari: Gde ste upotrebili samo nazive voća, jer se i tabela Voce sastoji samo od ključeva - svog i prenesenih iz Sorte i Klase. Usvim ostalim tabelama i upitima koji imaju veze sa voćem već je složeni naziv, a (drugo): ma koliko detaljan bio ne vidim u kom ste momentu (u kom Upitu ili Tabeli) izvršili "spajanje" naziva voća sa sortom i klasom.
Pozdrav!

Ovo sam uradio u trenutku prebacivanja podataka. Mnogo puta sam bio u situaciji da ovo uradim. Uglavnom ljudi krenu onim putem kojim ste i Vi. Predmet poslovanja je jako vazan sifarnik i njega treba dobro definisati. U razvijenim firmama, koje imaju jaku sluzbu razvoja (nazalost danas je sve manje takvih kompanija kod nas), ona se brine o tome i definise prave standardizovane nazive i ostale opsine atribute.



Pogledajte sliku...

Ipak se ne mogu praviti da sam razumeo.
- IDPartner mi je jasno čemu služi i za sada neka ostane na tome.
- Ali "Ovo sam uradio u trenutku prebacivanja podataka" mi nikako nije jasno. Na šta se odnosi termin "prebacivanje podataka"? A bitno mi je da bi moja Baza bila identična Vašoj i da ne pričam o tome koliko mi je bitno da razumem šta radim.
- Nije samo manjak takvih kompanija, nego je manjak i ljudi i timova koji bi hteli i umeli da problemu (i poslu) priđu i po širini i po dubini.
Pokušaću da završim obrasce tipa Dokument, a onda krećem na dopune za Prijemnice (i Otpremnice).

ps: Jasno mi je da Vas nekad (uglavnom uvek) "gušim" svojim neznanjem i nesnalaženjem. I za to nemam baš nikakvo opravdanje. Jedino mogu reći da sam malo više "vizuelan" tip - najjasnije mi je ono što vidim (uz objašnjenje).

Negde na početku ste stvaili svoju bazu i tom prilikom je bilo podataka u njoj modelirano prema Vašem viđenju stvari. Da bi se definisao jedinstveni entitet za predmet poslovanja morao sam da preformulišem nazive koje ste definisali sa aspekta generalizacije i tom prilikom je bilo potrebno prebacivanje podataka iz vaših tabela u tabelu PredmetPoslovanja.

Sad razumem gde je moj problem! Prebacivanje podataka je urađeno i završeno na početku stvaranja Baze od postojećih podataka, i to je OK. Ali šta posle - tj. sad, kad se dopuni neka nova vrsta voća, ili postojeća sa novom sortom? U tabelu Predmet poslovanja će biti prenesen samo naziv tog voća bez dodatka za sortu i klasu. Ja bih napravio izraz za spajanje (ali mislim da to u ovom slučaju nije dovoljno rešenje), mislim da je ipak potrebno sledeće: Napisati VB kod da u nekom trenutku prilikom slanja podataka iz forme PredmetPoslovanja-Voce ka tabeli PredmetPoslovanja izvrši "Trim"-ovanje naziva voća, naziva sorte i oznake klase. Ovo "...u nekom trenutku..." kažem jer nisam siguran da li bi kod trebalo pisati u formu Predmet poslovanja - Voće, ili u QVoce ili možda čak i u tabelu PredmetP... (mada mislim da se u tabele ne pišu kodovi). Koristim verziju Baze bez Upita dodavanja.
Pozdrav!

Pozdrav Zoranu, Trtku, Getsbiju i ostalima.
Dok čekam odgovor na moju prethodnu poruku (nadam se da ću ga dobiti), pojavio mi se neočekivani problem. Obrazac Dokument koji sam kreirao i završio vidljiv je samo iz dizajn pregleda, dok iz prikaza obrasca i prikaza rasporeda nema ničega, sem boje pozadine. Ovo važi za srednji deo obrasca - pojedinost, a zaglavlje i podnožje obrasca se vide redovno.
Šta se sada desilo?

Evo kreirah i sledeći obrazac - DokumentLista. i opet isto. Mogu da ga vidim samo u pregledu dizajna i da ga uređujem, ostalo ništa. Probao sam u novoj (nasumičnoj) bazi - sve je redovno. Probao sam u postojećoj bazi, koju radim i sa kojom imam problem (Hladnjača) da kreiram neki probni (nasumični) obrazac - takođe je sve redovno.
Pozdrav!

Nisam stigao da Vam odgovorim na bas nesjana pitanja, ali da vidimo taj Vas problem novi sta je to okacite primer?

1. Ovo je Baza kod koje se kod mene ne vide obrasci Dokument i DokumentStavka (osim u pregledu dizajna). I prethodna poruka mi je u vezi ove situacije.
2. Beleške o izmenama:
- U Tabelu DokumentStavka dodate kolone: TezinaPalete, TaraTezina (umesto - Kolicina), BrojAmbalaza, CenaStavke (umesto - Iznos), što je sve pridodato Obrascu DokumentStavka;
- U QDokumentStavka dodata polja za: TezinaPalete, BrojAmbalaza i NetoTezina (izračunato polje); zatim promenjeni nazivi polja Iznos u CenaStavke i Kolicina u TaraTezina. Prdodata povezana tabela Ambalaza iz koje uzimama podatke za AmbalazaID (naziv ambalaže) i polje koje bi trebalo zavisiti od ovog polja - TezinaPrazneAmbalaze.
- U Obrascu DokukentStavka promenjeno: Iznos u CenaStavke, Količina u TaraTezina i dodate kontrole za: NetoTezina, TezinaPalete, AmbalazaID i TezinaPrazneAmbalaze.
Pitanje: Kako da mi (u obrascu DokumentStavka) okvir TezinaPrazneAmbalaze zavisi od NazivaAmbalaze (AmbalazaID), a da ne bude ComboBox - kao kod Vas zavisnost JM od PredmetaPoslovanja?
U VB kodu DokumentStavka sam zamenio reči Iznos sa CenaStavke i reč Kolicina sa NetoTezina.
Ove izmene sam napravio kako bih imao poseban izgled DokumentStavke za Prijemnice i Otpremnice, dok bi Vaša verzija DokumentStavke koristila za Zaduženje Robe, Ambalaže i Avansa.
Pitanje: Da li su ove izmene korektno urađene?
Poštovanje!

Odgovor na ovo pitanje imate u prilogu. Problem su veze ili jos bolje receno Select naredbe koje su RecordSource i za Dokument i za DokumentStavka.




A sto se ostalih pitanja tice, da bi se dao valajn odgovor postavio bih pitanje:
Da li prilikom jednog prijema ili otpreme recimo voca moze da se dogodi da isti predmet poslovanja bude zaprimljen ili otpremljen u razlicitim ambalazama?

Ko zna - zna, ko ne zna nek pita! Da, to je to.
Može li objašnjenje ovoga. Vidim da je relacija bila suvišna, zašto?
Trenutni "manji" problemi:
- Kad iz obrasca VrstaDokumentaLista hoću da otvorim bilo koju vrstu dokumenta, javlja mi: "Run-time Error 2465", "...ne može pronaći polje u DokumentStavka na koje se pozivate u lzrazu". Nešto u vezi izvora redka (RowSource) za PredmetPoslovanjaID, ali ne znam šta. Opet nešto ne vidim.
- Kod otvaranja obrasca Dokument imam grešku 94. Nešto kod "Vrste" i vrednosti Null. Naravno, ni ovo mi nije najjasnije.
Inače, na Vaše pitanje, odgovor je ne - nema prepakivanja. Ambalaža je, u ovom slučaju, ista od Prijema, preko stanja u Hladnjači do Otpreme.
Pozdrav!

Stoji "Stavka", a treba "DokumentStavka", pogledajte u prilogu. Preciznost izrazavanja je veoma vazna...

Primer iz programiranja:

"Ubiti ga ne, pustiti ga"
"Ubiti ga, ne pustiti ga"


Formu Dokument, zamislio sam da otvarate samo i iskljucivo samo iz forme VrstaDokumentaLista gde se prosledjuje kao argument vrednost VrstaDokumentaID u svrhu deklarisanja Default vrednosti. Mozda sam mogao da uradim na neki drugaciji nacin ali u tom trenutku mi je bila ta inspiracija i naravno vreme...

Sto se tice Ambalaze i tezina... moze se i na takav nacin preslikati realni sistem s time sto bih racunanja odradio u upitu tj QDokumentStavka.

Da, ja sam promenio naziv podobrasca na pogrešnom mestu.

Pošto se ne možemo "čuti", verovatno zbog usklađenosti vremena, evo javljam Vam se preko foruma. Šaljem i dva fajla na proveru ispravnosti.
1. Ovo je moja verzija klasifikatora posle pročitanog "Projekta interne standardizacije". Mislim da sam shvatio suštinu potrebe za dobrom, ispravnom i efikasnom klasifikacijom i potrebom njene primene kod modelovanja Baza podataka. Znam da mi je greška što sam neke predmete poslovanja postavio kao klasifikatore, ali hteo sam da to vidite i da se uverim da to ne može. Moje pitanje u vei klasa ili vrsta je:
- Da li je "ident broj" (simbol je - IB) kod klasifikacije, ustvari - ID predmeta poslovanja? Ovo me buni jer negde u "Projektu" piše da IB treba optimalno imati 6 do 8 cifara?
- Da li se kod klasikacione šifre mogu kombinovati oznake cifara i slova, ili je pravilo - ili slova, ili cifre?
2. Šaljem Vam Bazu sa urađenim nazivima predmeta poslovanja.
Pozdrav!

Paralelni sistem oznacavanja predstavlja identifikaciju objekata od interesa posmatranja putem IDentifikacije i KLASifikacije.
Nemojte da Vas zbunjuje ID broj sa ogranicenom kolicinom cifara (malo je to zastareli pogled tj o internoj standardizaciji je pisano u doba kada se u svemu stedelo) zbunjuje.



Svakako da moze, upravo definisanje klasifikacije i klasifikacionog broja je pogled sa strane realnog sistema kako on vidi prirodu stvari.