Da li polje AutoNumber može da bude oblika 01/08, 02/08.....,gde 08 označava godinu i kako.
Polje AutoNumber kao 01/08
Zaključano
Zakačeno
ne može, AutoNumber je isključivo long integer tip. a druga stvar je što ovakav broj kakav daješ za primer nije nešto što se čuva u bazi. zašto? jer se broj može generisati iz dva druga podatka (redni broj i
godina dokumenta). znači napravi da ti se tamo gde prikazuješ taj broj (u izveštaju ili gde već) generiše ovakav izlaz. nešto kao - tabela.ID & "/" & Year(tabela.Datum).
godina dokumenta). znači napravi da ti se tamo gde prikazuješ taj broj (u izveštaju ili gde već) generiše ovakav izlaz. nešto kao - tabela.ID & "/" & Year(tabela.Datum).
Ovde se očigledno radi o broju dokumenta (fakture, profakture, otpremnice...)
ID polje (autonumber) ne bi trebalo nikada koristiti za određivanje broja dokumenta.
Napravi u tabeli posebno polje BROJ_DOKUMENTA
Primer
Tabela: PRODAJA
Polje: PRODAJA_BROJ
Na formi kao default value za PRODAJA_BROJ: Nz(DMax("PRODAJA_BROJ";"PRODAJA";"Year(PRODAJA_DATUM)=Year(Now())");0)+1
Na formi TextBox: txtBrFakture
(Control Source)="Faktura Br. " & Me.PRODAJA_BROJ & "/" & Year(Me.PRODAJA_DATUM)
ID polje (autonumber) ne bi trebalo nikada koristiti za određivanje broja dokumenta.
Napravi u tabeli posebno polje BROJ_DOKUMENTA
Primer
Tabela: PRODAJA
Polje: PRODAJA_BROJ
Na formi kao default value za PRODAJA_BROJ: Nz(DMax("PRODAJA_BROJ";"PRODAJA";"Year(PRODAJA_DATUM)=Year(Now())");0)+1
Na formi TextBox: txtBrFakture
(Control Source)="Faktura Br. " & Me.PRODAJA_BROJ & "/" & Year(Me.PRODAJA_DATUM)
Citat:
Catch 22: ID polje (autonumber) ne bi trebalo nikada koristiti za određivanje broja dokumenta.
zbog čega tako misliš?
Vjerovatno zato sto ako krenes unos pa odustanes taj broj se preskace, odnosno slijedeci put ce ti dodjeliti broj vise bez obzira sto nema unosa za taj broj, pa ces imati bezpotrebno preskocene brojeve
Slažem se sa DarioBH, ali moram dodati jos jednu stvar iz ličnog iskustva. Šta ako klijenti jednostavno odluče da obrišu poslednji dokument nakon njegovog štampanja, onda će drugi dokument doći pod istim tim brojem. Zbog toga AutoNumber ne deluje kao loše rešenje, ali je mislim ipak najbolje imati jednu tabelu sa najvećim brojevima pojedine vrste dokumenata.
Potpis
Ozbiljan i odgovoran mladić
U svim Access "bukvarima" stoji savet da se ID polje koristi isključivo za ono čemu je namenjeno kao primarni index (Primary Key)... Objašnjenje zašto postoji i u samom helpu, a bilo bi preopširno to razglabati ovde...
Autonumber ne mora da bude "increment", može da bude i "random" pa onda brojevi ne idu redom, zavisi kako ga definišeš... nekada je i bolje da bude "random"...
Autonumber ne mora da bude "increment", može da bude i "random" pa onda brojevi ne idu redom, zavisi kako ga definišeš... nekada je i bolje da bude "random"...
mene interesuje tvoje mišljenje, ne šta piše u Access Help-u. ne
mislim da je to tako jednostavna odluka, jer ima i dobrih i loših
strana, pa me interesuju argumenti i jednih i drugih. možemo otvoriti
i novu temu.
mislim da je to tako jednostavna odluka, jer ima i dobrih i loših
strana, pa me interesuju argumenti i jednih i drugih. možemo otvoriti
i novu temu.
Da se malo vratimo na pitanje (ideju) iz naslova teme... Kako će se rešenje sa autonumber ponašati u sledećoj kalendarskoj godini?
Dokumenti (fakture...) se obično ponovo vode od red.br.1 kada se uđe u novu kalendarsku godinu?
Primer koji sam gore dao vodi računa o tome...
Naravno da se cela stvar detaljnije razrađuje, kasnije tokom izrade aplikacije... pravi se procedura, koja proverava dodelu rednog broja... postoji puno raznih rešenja, sve zavisi "šta bi tačno pisac želeo da kaže"...
ID polje ima svoju osnovnu funkciju identifikatora svakog pojedinačnog unosa u tabeli... koristi se za primarno indeksiranje i pravljenje relacija kod povezivanja tabela, referenci na pojedinačni unos itd... generalno je loša ideja koristiti ga izvan namenski definisanih funkcija...
Dokumenti (fakture...) se obično ponovo vode od red.br.1 kada se uđe u novu kalendarsku godinu?
Primer koji sam gore dao vodi računa o tome...
Naravno da se cela stvar detaljnije razrađuje, kasnije tokom izrade aplikacije... pravi se procedura, koja proverava dodelu rednog broja... postoji puno raznih rešenja, sve zavisi "šta bi tačno pisac želeo da kaže"...
ID polje ima svoju osnovnu funkciju identifikatora svakog pojedinačnog unosa u tabeli... koristi se za primarno indeksiranje i pravljenje relacija kod povezivanja tabela, referenci na pojedinačni unos itd... generalno je loša ideja koristiti ga izvan namenski definisanih funkcija...
slažem se za ovo u vezi sa godinom. ali nameće se pitanje koliko se
godina može čuvati u jednoj Access bazi bez gubitaka performansi.
susretao sam i praksu "prenošenja" potrebnih podataka iz jednog u
drugi MDB fajl pri otvaranju početnog stanja.
druga stvar, a isto u vezi sa pitanjem, jeste sama priroda tog
famoznog rednog broja dokumenta. nije li on sam po sebi jedinstven?
(makar bi trebalo da bude u dobro projektovanom sistemu.) samim tim se
upotreba dodatnog AutoNumber polja za primarni ključ čini izlišnom.
mislim da se ovom problemu može pristupiti sa više strana, tako da bih
voleo da čujem sva mišljena.
godina može čuvati u jednoj Access bazi bez gubitaka performansi.
susretao sam i praksu "prenošenja" potrebnih podataka iz jednog u
drugi MDB fajl pri otvaranju početnog stanja.
druga stvar, a isto u vezi sa pitanjem, jeste sama priroda tog
famoznog rednog broja dokumenta. nije li on sam po sebi jedinstven?
(makar bi trebalo da bude u dobro projektovanom sistemu.) samim tim se
upotreba dodatnog AutoNumber polja za primarni ključ čini izlišnom.
mislim da se ovom problemu može pristupiti sa više strana, tako da bih
voleo da čujem sva mišljena.
Kad god mogu da od kandidata za PK odaberem prirodni ključ (nešto iz realnog šivota), ja to uradim. Recimo skraćene oznake jedinica mera: kg, lit, met, kom..... (tabele sa relativno malim brojem zapisa).
No kako se to retko dešava onda naravno kao i svi pribegavam veštačkim ključevima: PartnerID, ArtikalID, MestoID.....
Kad ne želim da upravljam dodeljivanju brojeva u okviru ID broja, recimo partnera, onda to prepuštam Access-u i tipu polja Autonumber.
Kada mi je važno da pratim redosled dokumenata, u slučaju ozbiljnijeg modela podataka koji se odnosi recimo na finansijsko knjigovodstvo gde postoji veći broj vrste dokumenata, onda izbegavam Autonumber i pribegavam rešenju koje je pomenuo kolega domaci_a_nas. Tada pravim zasebnu tabelu sa vrstama dokumenata i maksimalnim brojem u okviru vrste. Ovde ide sve ono što podrazumeva praćenje jedne takve evidencije. Primer: Tabela finansijskih naloga za knjiženje. Primarni ključ je složeni. Numeracija je u okviru vrste dokumenta. Ovde koristim tip Integer. Može i Long Integer, ako su vam predpostavke da će "n" biti veće od 36000.
BL/1.........BL/n -------- blagajna
TR/1........TR/n -------- tekuci racun
UK/1........UK/n --------- ulazna kalkulacija
.
.
E sad, iskustva su različita. Afiniteti takođe. Uvek može da se čak i loše projektovana tabela izgura kroz aplikaciju ako postoji znanje iz programiranja, što naravno ne preporučujem. Sećam se jednog mog profesora koji je govorio. „Nemojte da radite kao što ja radim, već kako vas učim da treba.“
Što se tiče pitanja koje je postavio kolega lukeguy “...više godina u jednoj bazi...”, tu koristim sledeću logiku. Ako je u pitanju izolovani poslovni problem, tipa: „Praćenje faktura“ ili „Materjalno knjigovodstvo jednog magacina“, onda uvodim godinu u broj dokumenta i dozvoljavam podatke više kalendarskih godina u jednoj bazi. Kada je u pitanju Finansijsko računovodstvo (knjigovodstvo sa bilansima), tada držim svaku godinu u zasebnoj bazi ili bolje rečeno svake godine otvaram novu.
Razlozi:
1. sve je proknjiženo,
2. urađen završni račun,
3. automatski prenešena stanja po kontima u drugu godinu.
4. ne postoji potreba ( a nije ni dozvoljeno) da se podaci ažuriraju.
Ovo sve važi za OLTP aplikacije kojima se mi ovde bavimo. Da je u pitanju OLAP aplikacija, sigurno bih sve držao u jednoj bazi i insistirao na jačem hardveru. Kod OLAP aplikacija predpostavke su sledeće: Data Warehousing (skladište podataka), denormalizovan podaci, definisane hijerarhije, kreirane agregacije.... a to pre svega uslovljeno potrebom menadžera da mogu dobiti svaku realnu informaciju u što kraćem vremenu iz kompletnog višegodišnjeg poslovanja.
No kako se to retko dešava onda naravno kao i svi pribegavam veštačkim ključevima: PartnerID, ArtikalID, MestoID.....
Kad ne želim da upravljam dodeljivanju brojeva u okviru ID broja, recimo partnera, onda to prepuštam Access-u i tipu polja Autonumber.
Kada mi je važno da pratim redosled dokumenata, u slučaju ozbiljnijeg modela podataka koji se odnosi recimo na finansijsko knjigovodstvo gde postoji veći broj vrste dokumenata, onda izbegavam Autonumber i pribegavam rešenju koje je pomenuo kolega domaci_a_nas. Tada pravim zasebnu tabelu sa vrstama dokumenata i maksimalnim brojem u okviru vrste. Ovde ide sve ono što podrazumeva praćenje jedne takve evidencije. Primer: Tabela finansijskih naloga za knjiženje. Primarni ključ je složeni. Numeracija je u okviru vrste dokumenta. Ovde koristim tip Integer. Može i Long Integer, ako su vam predpostavke da će "n" biti veće od 36000.
BL/1.........BL/n -------- blagajna
TR/1........TR/n -------- tekuci racun
UK/1........UK/n --------- ulazna kalkulacija
.
.
E sad, iskustva su različita. Afiniteti takođe. Uvek može da se čak i loše projektovana tabela izgura kroz aplikaciju ako postoji znanje iz programiranja, što naravno ne preporučujem. Sećam se jednog mog profesora koji je govorio. „Nemojte da radite kao što ja radim, već kako vas učim da treba.“
Što se tiče pitanja koje je postavio kolega lukeguy “...više godina u jednoj bazi...”, tu koristim sledeću logiku. Ako je u pitanju izolovani poslovni problem, tipa: „Praćenje faktura“ ili „Materjalno knjigovodstvo jednog magacina“, onda uvodim godinu u broj dokumenta i dozvoljavam podatke više kalendarskih godina u jednoj bazi. Kada je u pitanju Finansijsko računovodstvo (knjigovodstvo sa bilansima), tada držim svaku godinu u zasebnoj bazi ili bolje rečeno svake godine otvaram novu.
Razlozi:
1. sve je proknjiženo,
2. urađen završni račun,
3. automatski prenešena stanja po kontima u drugu godinu.
4. ne postoji potreba ( a nije ni dozvoljeno) da se podaci ažuriraju.
Ovo sve važi za OLTP aplikacije kojima se mi ovde bavimo. Da je u pitanju OLAP aplikacija, sigurno bih sve držao u jednoj bazi i insistirao na jačem hardveru. Kod OLAP aplikacija predpostavke su sledeće: Data Warehousing (skladište podataka), denormalizovan podaci, definisane hijerarhije, kreirane agregacije.... a to pre svega uslovljeno potrebom menadžera da mogu dobiti svaku realnu informaciju u što kraćem vremenu iz kompletnog višegodišnjeg poslovanja.
Code:
="Faktura Br. " & Me.PRODAJA_BROJ & "/" & Year(Me.PRODAJA_DATUM)
="Faktura Br. " & Me.PRODAJA_BROJ & "/" & Year(Me.PRODAJA_DATUM)
kako da za godinu pokaze samo zadnje 2 cifre ("09").
Potpis
Nemam pojma šta da stavim u potpis!
Uprkos tvom veoma odbojnom nadimku, zbog kojeg sam više puta potpuno ignorisao tvoje komentare, evo ipak odgovora:
Code:
="Faktura Br. " & Me.PRODAJA_BROJ & "/" & Right(Year(Me.PRODAJA_DATUM),2)
="Faktura Br. " & Me.PRODAJA_BROJ & "/" & Right(Year(Me.PRODAJA_DATUM),2)
Potpis
"Take Five" is the famous jazz piece written by Paul Desmond and performed by The Dave Brubeck Quartet. It is famous for its distinctive saxophone line and use of the unusual quintuple (5/4) time, from which its name is derived.
Take Five (1966)
Take Five by Al Jarreau 1976
Take Five (1966)
Take Five by Al Jarreau 1976
hvala ti!
Potpis
Nemam pojma šta da stavim u potpis!
interesuje me kako regulisati prelazak u sledecu godinu? kako da access sam kad vidi godinu 2010 krene da broji iz pocetka. i posle tako za sve ostale godine u buducnosti. recimo 78/09, 79/09 i sad je recimo 1.1.2010. i on odma upisuje 01/10 i tako dalje...
druga stvar. kako da access jednocifrene brojeve prikaze sa 0 ispred (01/09,...05/09,...09/09)?
druga stvar. kako da access jednocifrene brojeve prikaze sa 0 ispred (01/09,...05/09,...09/09)?
Potpis
Nemam pojma šta da stavim u potpis!
Citat:
Srbin do jaja: interesuje me kako regulisati prelazak u sledecu godinu? kako da access sam kad vidi godinu 2010 krene da broji iz pocetka. i posle tako za sve ostale godine u buducnosti. recimo 78/09, 79/09 i sad je recimo 1.1.2010. i on odma upisuje 01/10 i tako dalje...
druga stvar. kako da access jednocifrene brojeve prikaze sa 0 ispred (01/09,...05/09,...09/09)?
druga stvar. kako da access jednocifrene brojeve prikaze sa 0 ispred (01/09,...05/09,...09/09)?
Moje osobno mišljenje je da je bolje odvajat baze za poslovne godine. Ako baš želiš da bude sve u istoj, možeš uspoređivati datum računa sa datumom na zadnjem računu... Ili drži negdje zapisanu konstantu o godini, i ako je godina iz datuma različita...
ne moraš u bazi držati 01. Kod ispisa gledaj dužinu stringa i onda dodaj znakove ispred. Isto kao i za nastavke /09.
Potpis
F
kod razdvajanja baza, postoji jedna stvar koja bi mi smetala ili se meni cini da to drugacije ne moze. morao bih posle rucno menjati query-je i stelovati bazu. ili postoji neka automatizacija ili jednostavno resenje? ili da na kraju godine napravim novu tabelu i prebacim podatke za prethodnu godinu u novu tabelu uz pomoc query-ja?
Potpis
Nemam pojma šta da stavim u potpis!
Citat:
Srbin do jaja: kod razdvajanja baza, postoji jedna stvar koja bi mi smetala ili se meni cini da to drugacije ne moze. morao bih posle rucno menjati query-je i stelovati bazu. ili postoji neka automatizacija ili jednostavno resenje? ili da na kraju godine napravim novu tabelu i prebacim podatke za prethodnu godinu u novu tabelu uz pomoc query-ja?
Ako trebaš ručno štelovati query-e, onda su loše napisani. Treba pisati parametrizirane query-e, a ne stavljati konstante tipa godine u upite. Najbolje bi bilo da napraviš, kako ti kažeš automatizaciju da se kreira ista takva baza (prazna) i onda iz stare pokupiš podatke koji ti trebaju u novoj godini. Ako te muči kako češ znati u kojoj godini trenutno korisnik radi, to lako riješiš tako da kod otvaranja programa pitaš korisnika koju godinu želi otvoriti i ovisno o tome pozoveš tu bazu (npr. BAZA_2008). Upiti ti onda izgledaju ovako nekako:
SELECT * FROM NEKA_TABLICA WHERE GODINA = :GODINA
Istina da je malo teže razdvajati baze nego imati sve na jednom mejstu, ali razmišljaj da će ti nakon par godina vjerojatno biti jako puno podataka u bazi, gubit će na brzini itd itd...
Nadam se da sam pomogao.
Potpis
F
Pogledati
http://www.personalmag.rs/software/kvalitet-softvera-i-standardi/. Tako
da mislim da nema potrebe raspravljati o raznoraznim sistemima rada i
sizmišljati rupu na saksiji. Sve je već regulisano i poznato, samo treba
primeniti i ništa više.
http://www.personalmag.rs/software/kvalitet-softvera-i-standardi/. Tako
da mislim da nema potrebe raspravljati o raznoraznim sistemima rada i
sizmišljati rupu na saksiji. Sve je već regulisano i poznato, samo treba
primeniti i ništa više.
nisam upoznat sa razdvajanjem baza. jos uvek sam pocetnik i ucim. ako mozes to malo objasniti ili da postavis neki link da procitam o tome bio bih ti zahvalan.
Potpis
Nemam pojma šta da stavim u potpis!