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).

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)

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.

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"...

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.

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...

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.

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.

kako da za godinu pokaze samo zadnje 2 cifre ("09").

Uprkos tvom veoma odbojnom nadimku, zbog kojeg sam više puta potpuno ignorisao tvoje komentare, evo ipak odgovora:

hvala ti!

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)?

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.

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.

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.

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.

Pregledaj poruke od Zidara na ovom forumu ima dobro reesenje za to.Nemam vremena da trazim

Pre postavljanja pitanja prvo pročitaš komentare u temi u kojoj učestvuješ.
Odgovor na tvoje pitanje je dat na samom početku teme (vidi treći komentar)

broj_trt=1

da bi dobio "01"

ispis=format(broj_trt,"00")

za "0001"

ispis=format(broj_trt,"0000")

itd....

Pokušavam ovo ubacit u svoju tablicu ali nešto šteka:

Dakle imam
tablicu Racun

polje Broj_racuna, i Datum_racuna

i predhodni kod sam ovako iskorigirala

Na formi kao default value za Broj_Racuna: Nz(DMax("Broj_racuna";"Racun";"Year(Datum_racuna)=Year(Now())");0)+1

Na formi TextBox: txtBroj_racuna

(Control Source) ="Racun br. " & Me.Broj_racuna & "/" & Year(Me.Datum_racuna)"

I stalno mi izbacuje error #Name?

Na control source postavi ime polja gde ti se broj upisuje

Na Control source sam upisala izraz ="Broj_racuna " & Me.Broj_racuna & "/" & Year(Me.Datum_Racuna), ako upisem samo naziv polja "Broj_racuna" također mi daje error

Control Source predstavlja ime tabele i polja gde se upisuje vrednost iz kontrole, odnosno samo ime polja posto ti je forma verovatno povezana sa tabelom ili querijem.
Znaci u kontrol source se upisuje samo ime polja, bez navodnika i nikakvih racunskih znakova, ili se ostavlja prazno (unbound)

Dakle ja pokusavam rijesiti problem spomenut na pocetku teme

"Da li polje AutoNumber može da bude oblika 01/08, 02/08.....,gde 08 označava godinu i kako?"

Na što je dan sljedeci odgovor:

"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)"

I ja ga pokusavam primjeniti na svoju tablicu tj. polje

Dakle

Tabela: RACUN
Polje: BROJ_RACUNA
Na formi kao default value za BROJ_RACUNA: Nz(DMax("BROJ_RACUNA";"RACUN";"Year(DATUM_RACUNA)=Year(Now())");0)+1

Na formi TextBox: txtBroj_racuna
(Control Source)="Racun Br. " & Me.BROJ_RACUNA & "/" & Year(Me.DATUM_RACUNA)"


Kada sa ovakvim postavkama pokrenem formu u polju gdje bi se trebao pojaviti broj izbacuje mi gresku.

Okaci tu tvoju bazu pa da vidimo u cemu je problem.

Moja ti je preporuka da iapk ne spajas BrojProdaje sa godinom, broj prodaje mozes ostaviti u posebnom polju a kasnije gde ti je potrebno spojis godinu i broj prodaje. Jer kad ti je spojeno neces moci funkcijom DMax naci koji ti je zadnji broj prodaje, ako ti je broj prodaje 01/08 razumece ga kao string a ne kao integer, a za string ne mozes naci Max vrednost.

Imate primer na ovom linku http://www.elitesecurity.org/t412932-0#2723860