OK, slazemo se da ugovori I anksi nisu isto. Sada znamo da protumacimo nazive tabela u postojecoj bazi. Preporucujem da ne preradjujes bazu da bi je postavio na forum, jer nece biti dobra u svakom slucaju. Problem nije naivan ali je potpuno resiv.
Hajde da za pocetak nazovemo stvari pravim imenima. Neka tabela Ugovori predstavlja - ugovore, a tabela Aneksi anekse. Imaces dakle za jedan ugovor vise aneksa. Ovako nekako:
Code:
Ugovori: {(UgovorId,int), (VaziOd, datetime),PrestajeDaVaziOd, datetime),(Klijent,int)
PRIMARY KEY (UgovorID)
}
Aneksi: {(UgovorId,int), (BrojAneksa,int), (AneksVaziOd,datetime)
PRIMARY KEY (UgovorID,BrojAneksa)
FOREIGN KEY (UgovorID) REFERENCES Ugovori(UgovorID)
}
Primetite zgodan ancin da se logicki opisu tabele, kao skupovi parova (NazivKolone,TipPodatka)
Kako da resimo stavke ugovora i dodtne stavke na aneksima? Zdrav razum nam kaze da nam treba nesto kao [Stavke ugovora] I [Stavke aneksa], vezne tabele izmedju tabele Proizvodi i tabela Stavke i Aneksi. Logicki, potpuno ispravno. Fizicki, nije dobro. Zasto? Nismo kazali nigde nesto sto je logicno i podrazumeva se, toliko se podrazumeva da to ni ne spominjemo - ankesi i ugovor ne smeju da imaju iste stavke. Ako je neki proizvod pokriven ugovorom, ne mozemo imati isti taj proizvod u nekom od aneksa. Ovaj uslov se tesko moze zadovoljiti ako su Stavke ugovora i Stavke Aneksa zasebne tabele. Sledi da nekako treba cuvati stavke u istoj tabeli, bez obzira da li pripadaju ugovoru direktno ili aneksima. Resenje koje prizilazi iz ovog rezonovanja je iznenadjujuce jednostavno:
Code:
Stavke: {(UgovorId,int), (BrojAneksa,int), (ProizvodID,int), (Kolicina,int),(Rabat,decimal)
, PRIMARY KEY (UgovorID, ProizvodID)
/* ovim postizemo da se jedan proizvod moze pojaviti na jednom ugovoru ne vise od jedan put */
, FOREIGN KEY FK1: (UgovorID, BrojAnkesa) REFERENCES Aneksi (UgovorID,BrojAneksa)
/* stavke pripadaju tabeli Aneksi! */
, FOREIGN KET FK2: (ProizvodID) REFERENCES (Proizvodi)
}
Neko ce se zapitati - ako stavke pripadaju aneksima, sta je sa stavkama koju pripadaju samom ugovori, pre aneksa? Uvescemo nulti aneks. Kad insertujete Ugovor, insertujte I Aneks sa rednim brojem 0. To ce biti inicijalne stavke - aneks 0 predstavlja sam ugovor. Kasnije dodajete anekse 1,2,3..N I svakom doidajete stavke. Ako napravite tabele u Accesu, videcete da imate u stavri trostepenu hijerarhiju Aneks->Ugovor->Stavka. To znaci da forma-subforma nece moci da radi za slucaj kad unosite podatke u nulti aneks, ali se to moze isprogramirati. Svako ko hoce da se nazove profesinalnim programerom mora da zna kako se programira unos podataka u trostepene hijerarhije. Dvostepena hijerarhija je forma-subforma, to zna svako ko pogleda Microsoft tutorials. ostavljam postavljacu pitanaj da se pomuci sa unosom stavki za nulti aneks.
U svakom slucaju, na nivou baze smo postigli da se lako unose stavke gde treba. Kad ih treba preneti u sledeci mesec, jednostavno sve stavke koje pripadaju jednom ugovoru prebacite u nulti aneks za sledeci mesec. Ako neke stavke ne zelite da prenesete, jednostavno ih obrisete. Ako treba da dodate nove stavke - onda prvo definisete aneks, pa za taj aneks mozete fomom i subformom da uneste dodatne stavke. Za sledeci mesec, ponovit ovo sve.
Postoje i druga resenja, verovatno, ko ima ideju slobodo napred, pa da vidimo dokle cemo stici.
Nadam se da je pomoglo.
Kopiranje više podataka u istoj tabeli (Forma i SubForma)
