Ne možeš sabirati u tabeli, a nema ni portebe za tim. Tabele u Accesu služe za skladištenje podataka, a čuvati podatke koje možeš uvek izračunati je bespotrebno trošenje resursa. Za izračunavanja, filtriranja, sortiranja, itd koristi Querije (upite)

Da naravno u tabela ma je skoro pa nemoguce sabrati dva polja ali za to napravis query od te tabele i dodas slobodnu vrijednost NPR : Iznos : [cijena]*[kolicina] ili putem forme na formi da sabires ta dva polja NPR : stavis prazan txtbox i u propertis na source stavis, = [cijena]*[kolicina] i onda samo zadas format na curency.

Et tako od prilike !

Ili ako za potrebe "History"-ja kao sto je bio slucaj kod mene kada zelis da znas tacno sta je odradjeno nekom akcijom mozes uraditi sljedece:

sabiranje polja a+b mozes obaviti u formi preko jedne komande koju cemo nazvati "Saberi".

U kodu, na "On Click" napravi funkciju koja ce rezultat sabiranja dodati u polje c istog record-a.

Naravno ovo je malo vise posla, ali ja sam morao ovako da bih izbjegao pokretanje querry-ja svaki put kad trebam da pregledam podatke.

@ nidisa
Znači da kad treba da pogledaš podatke pokrećeš tabelu u kojoj držiš izračunati vrednost. Kada bi pokretao query ti bi takođe pokretao tu tabelu samo što ne bi imao izračunati podatak u njoj. Važno je shvatiti da query nije nikakva tabela već samo izfiltrirani njen prikaz. Access čuva samo SQL zapis ili ono što vidiš kad prikažeš SQL View. Zato je mnogo bolje izračunate vrednosti ne držati u tabelama već ih u momentu (query-ji su brzi i efikasni) prikazati. Sa stanovišta boljeg raspolaganja resursima računara ova varijanta je daleko efikasnija. Nikakav "History" za podatke koji se mogu izračunati nije potrenaban. Histry služi za one transakcije koje su obrisane ili ažurirane, a trebalo bi da se vide pređašnja stanja.

Najpre,

Hvala puno svima na odgovorima.

Probacu da koncipiram problem malo bolje:

tabela sadrzi ime (text), datUnosa( dateShort), BRugradnja (number)

pacijent ima pravo da svakih 12 meseci od datUnosa dobije zamenu ortopedskog pomagala, a na svakih 24 meseca od DatUnosa pravo na novu ugradnju( tada se polje BRugradnja povecava za 1.


Potrebno mi je da pozivanje querija prikaze sve pacijente kojima je ovog meseca vreme za ugradnju, i drugi queri cije pozivanje prikazuje pacijente kojima je ovog meseca vreme za zamenu.


Unapred hvala

Napravi query sa svim podacima i dodaj jos jedno polje u koje ces u field upisati "Razlka: Date()-[datUnosa]" bez navodnika a postaviti da bude General Number i u polje Criteria upiši ">365" opet bez navodnika.

Ovo ce ti prikazati samo pacijente koji su upisani prije vise od 365 dana.

Dario hvala za odgovor, no meni je potrebno da mi upit vrati pacijente kojima je ovaj mesec vreme za izmenu/ugradnju.

napravio sam SQL UPIT ali nisam siguran d je dobar, radi ok, ali mi je potrebna jos necija potvrda.



Ova funkcija bi trebalo da vrati listu samo onih pacijenata kojima je tekuci mesec mesec za novu ugradnju. ( ugradnja se vrsi svake 2 godine od datUnosa).


Moze li neko da mi potvrdi da je funkcija dobra?

Ovo bi trebalo da bude ok, al mislim da ti nece raditi kod prve zamjene, nakon 12 mjeseci kad ti polje BRUgradnja bude imalo vrijednost "0"

Ispravka: radi ako kao default vrijednost polja stavis 1 a ne 0

Cini mi se da SELECT nije dobar. Ako pacijent ima novu ugradnju svake dve godine, onda ce tokom zivota pacijanta biti nekoliko novih ugradnji. Da bi odredio kome je potrebna nova ugradnja sledeceg meseca, moras da znas kada je bikla POSLEDNJA ugradnja za svakog pacijenta. E onda vidis da li je ta poslednja ugradnja za paciejnta stara dve ili vise egiduina u mesecima. Proizilazi da ti treba prvo SELECT koji ce da pronandje sve poslednje ugradnje i da se to uporedi sa tekucim mesecom. Tekuci mesec je mesec u kome je danasnji dan.

qryPoslednjaUgradnja:


qryKomeJeRedZaNovuUgradnju:


Kveri qryKomeJeRedZaNovuUgradnju izracunava razliku od danasnjeg dana do datuma poslednje ugradnje i ako je ta razlika 12 meseci ili vise, pacijent je na redu z anovu ugradnju. RedniBroj ugradnej tu ne igra nikakvu ulogu. Ako uneses u tabelu neki buduci datum, kad a se planira nova ugradnja, ovaj kveri ga nece pokazati (kao sto i treba) jer ce DatumUgradnej biti veci od danasnjeg datuma, pa ce DateDiff biti ili nukla ili negativno, sto ni jedno nije vece od 24.

"Zidar" mozes li mi molim te pojasniti ovaj deo tvog koda :




kako sam ja razumeo :

treba da uvedem jos dva polja u tabelu, datumPoslednjeUgradnje i datumPoslednjeIzmene (tipa ShortDate ).
pri cemu bih proveravao da li je datumPoslednjeUgradnje + 730 > Now() // za nove ugradnje nakon 2 godine od poslednje ugradnje
i datumPoslednjeIzmene + 730 > now() // za izmeme na koje pacijent ima pravo svakih 2 godine od poslednje izmene

Obzirom da tvoje resenje predstavlja, mnogo bolju varijantu od moje nesigurne funkcije.



Hvala

Ja sam pretpostavio da se svaka ugradnja unosi u tabelu kao poseban rekord. Onda sam pretpostavio da je DatumUnosa u stvari datum odredjene ugradnje. Ako nije, onda ti treba kolona 'DatunmUgradnje', da se vidi kad je nesto ugradjeno. Od svih unetih rekorda, jedna ce imati najveci (MAX) datum ugradnje. To je dakle datum POSLEDNJE ugradnje.Kad znas datum poslednje ugradnje, onda ga uporedis sa cim god hoces, u kojim god hoces jedinicama. Ako kolona datumUnosa ne znaci 'datum ugradnje', onda ti treba kolona za datum ugradnje.

ne znam u cemu se razlikuju IZMENA i UGRADNJA, ali ako su razlicite stvari, da, treba ti kolona datumskog tipa i za to.

Resio sam obavestavanje na svake 2 godine (gde je polje "izmena" datum poslednje izvrsene izmene) i to radi ok,




Jos samo jedno pitanje kao da proverim da li je polje za datum prazno,( to jest u da dobijem listu unosa cija su polja "novo" ne unesena)
iz nekog razloga koriscenje Null ne vredi.



i jos jednom hvala svima na pomoci