Vidi ovako, ako tvoja tablica Plan, kloja je u stvari ovo:
Plan (ProizvodID, Kolicina za mesec 1, Kolicina za mesec 2, Kolicina za mesec 3....Kolicina za mesec 12)
nema nikakvu drugu ulogu osim da se u nju unesu kolicine, bas onako kako bi to uradio u Excelu, onda OK, moze kako god hoces.
Medjutim, za bilo sta drugo jednostavno nece ici, ne zato sto tako kaze Zidar i nije lepo teorijski nego zato sto fizicki ne moze.
Sto se tice unosa u propisno organizovanu tabelu
(ID_Proizvoda, Godina, Mesec, Kolicina)
ne ocekujes da poverujem da ce se podaci unositi direktno u tabelu? Onda bi bilo 4 podatka da se unese umesto 1. Verujem da znas sat su forme i subforme, pa kad su subforme bound, onda se vezni podaci sami od sebe 'upisuju', korisnik ne mora ni da ih vidi, i tako dalje. Jos jedan razlog da budem veoma zabrinut klvalitetom ponudjenog resenja.
Ostajem pri oceni kvaliteta i ponavljam - nacin na koji se cuvaju podaci u bazi i nacin na koji ih korisnik vidi ili unosi nisu identicni. U veoma prostim slucajevima mogu da izgledaju slicno, ali u realnom ziovotu nikad se ne desava tako nesto. Ako tabele dizajniras tako da su one ogledalna slika front enda ili nekakvih izvestaja, onda si promasio profesiju. Ovakva tabela plan je ekvivalentna jednoj tabeli koja bi cuvala podatke za recimo Fakturu, gde bi imao polja
Faktura (KupacID, FakturaID, Proizvod1, Kolicina1, proizvod2, Kolicina2,.....ProizvodN, KoliicnaN)
Tako nesto vec ne bi uradio. Ili cuvas fakture za kupca ovako:
FaktureKupca (KupacID, Faktura1, Faktura2, Faktura2,Faktura4... FakturaN)
gde su Faktura1,2,3...N ukupne vrednosti pojedinih faktura. Ne verujem da bi ti ikad palo na pamet da uradis tako nesto. A tvoja tabela Plan izgleda upravo tako, ako smao zamenis Faktura1 sa KolicinaZaMesec1.
Sev i da uradi tako, imena kolona poput '1','2','3' ne kazuju nista onom ko pogleda u tabelu. da li su '1','2','3' meseci? Ili su to radne ejdinice? Ili su to radnici koji ce proizvesti proizvode? Ili su to kupci? Ti znas da su u tvom slucaju '1','2','3' mesec, ali niko drugi to ne zna.
Nadam se da sad razumes gde gresis. Nemam nista licno prtotiv tebe i nije mi namera da vredjam ili bilo sta. Ne kazem da ti ne umes da radis. Kazem da si u ovom konkretnom slucaju napravio katastrofalnu gresku. Pokusavam da ti ukazem na gresku, a ti radi kako hoces. A moram da naglas kazem da ne valja, jer i drugi citaju ovaj forum, pa ako vide ovakvo resenje, i niko nema nista protiv, pomislice da se to tako zaista i radi. Ne radi se. A veruj mi da sam na ovom trulom zapadu imao priliku da vidim vise puta da se developer otpusti zbog neznanja. Ne odmah, ne u trenutku kad napravi katastrofalnu gresku u dizajnu, vec kasnije, kad sistem zariba u kriticnom momentu.
Kad sam nekad radio kao inzenjer, katastrofalne greske nisu bile toliko moguce, jer se sav rad podnosio na uvid nekome starijem i iskusnijem, po zakonu, i na kraju se radila nezavisna revizija projekta, gde je drugi inzenjer, iskusan i ovlascen (van nase firme) pokusavao na sve nacine da pronadje sta ne valja u projektu sta nije po zakonu i propisima i po pravilima struke. Nazalost, u IT industriji toga nema i svako radi sta hoce i svakome se veruje u pocetku. Ali se greske veoma skupo placaju. Kao sto inzenjeri moraju da postuju fizicke principe (inace kuce bi se rusile kao lude) tako i oni koji razvijaju informacione sisteme moraju da postuju logicka pravila o oragnizovanju podataka. Inace se sistemi ruse, bas kao i kuce i mostovi.
Automatski unos datuma na formu na temelju podatka iz subforme
Re: Automatski unos datuma na formu na temelju podatka iz subforme
Re: Automatski unos datuma na formu na temelju podatka iz subforme