Zakaci bazu sa nekoliko test rekorda da vidimo sta moze da se uradi. Ovako kako si postavio pitanje, tesko je dati odgovor. Zakaci bazu najbolje, sa TEST podacima, ne mora da budu stavrni, pa ce se vec naci neko ko ce znati da pomogne.

Izvinjavam se za kasnjenje ...
U medjuvremenu sam probao sam nesto pronaci ali nista korisno. Zakacio sam testTabelu koja ima 1440 zapisa (toliko je minuta u jednom danu). U polju vrejednost je kumulativa iz koje moram dobiti potrosnju po satima, sto znaci 24 zapisa. Suma tih 24 vrijedosti mora biti jednaka razlici zadnjeg i prvog zapisa u testTabeli.
Bio bi puno zahvalan za to rijesenje jer program mi je inace gotov samo jos to fali. Ako podatke grupiram Format ili Hour funkcijom i onda od zadnje oduzmem prvu vrijednost dobijem za par % nižu sumu od gore pomenute razlike zadnjeg i prvog zapisa.

Hvala jos jednom.

Da li ste ovo zeleli?

Hvala za pokusaj ali to jos nije to. Suma utrosaka = 6767 dok je razlika izmedju kraja zadnjog i pocetka prvog = 6879.

Zoranova ideja je dobra, da se u okviru jednog sata gleda u potrosnje na krajevima.

Medjutim, ima jedna greska koja je dovela do pogresnog zbira. Momenti ocitanja nisu na ceo minut, ima one 24 sekunde kasnije. Zbog toga kveri QUtrosenoNaDanPoSatu ne vraca dobre kumulative u Kraj-Pocetak.

Za interval 0:00 do 1:00 imamo po kveriju
Pocetak:{Kumulativa = 13881358, Cas = '2010-10-22 12:00:24 AM')
i Kraj: {Kumulativa= 13881641, Cas = '2010-10-22 12:59:24 AM')
Razlika je tacna, RAzlika = 13881641 - 13881358 = 283

Za interval 1:00 - 2:00 imamo
Pocetak:{Kumulativa = 13881646, Cas = '2010-10-22 1:00:24 AM')
i Kraj: {Kumulativa= 13881929, Cas = '2010-10-22 1:59:24 AM')

POgresan je pocetak za 1:00 - 2:00. Pocetak svakog sata treba da se poklapa sa krajem prethodnog sata. Znaci, trebalo bi da bude pocetak za 1:00-2:00 isto sto i kraj za 0_00-1:00, a to je :{Kumulativa = 13881358, Cas = '2010-10-22 12:00:24 AM')

Otuda ona razlika, jer nedostaje po jedan interval na kraju svakog sata. Za pocetak, nedostaje 13881646-13881641, i tako za svaki sat po jedan.

Ako usvojimo da se kraj intervala korektno izracunava, onda mozemo da do korektnog pocetka dodjemo u dva koraka. Prvo izracunamo Kraj, onako kako kolega Zoran predlaze. Onda u sledecm koraku Kraj svakog sata napravimo da bude pocetak sledeceg sata. To ce biti OK za sve sate osim prvog (00:00), koji nema prethodni sat, pa ga moramo dodati nekako, sa nekim UNION ili tako nekakao. A moze i da se usvoji da je pocetak tacan, a da se izracunava Kraj u drugom koraku, kako vam drago.

Danas sam uvelikoj guzvi i ne mogu da ovo napisem, ali mislim da ima dovoljno elemenata da neko ovo resi. Ako nista ne bude do sutra, probacu da napravim kverije.

Hvala za odgovor. I ja sam shvatio da je problem u intervalu na 1 minutu dok brojac broji kontinuirano, zato i fali jedna minuta. Ako pogledamo zapise za recimo 14:00 jih je tocno 60 kao i kod svih drugih. Privremeno rijesenje je da potrosnji svakog sata programski dodam 1/60 (minutnu potrosnju) za svaki brojac posebno. Na taj nacin sam minimizirao gresku do granice prihvatljivosti. Ne mogu se igrati sa Union query-jem jer imam 85 brojaca i to bi stvar previse zkopliciralo. Tako i tako imam ogroman (171 kolona) query za izracun potrosnje po sistemu Group By Max - Min za svaki brojac posebno.
Zanimljivo je to kad upotrijebim dnevno ili mjesecno grupiranje onda te greske nema.

Hvala jos jednom za trud. Ako nekome uspije napraviti query koji bi to rijesio u nulu i bio prihvatljiv (zbog duzine) za 85 brojaca bi mi pao kamen sa tipkovnice.

Nije komplikovano, nadam se da cu sutra da ti to napravim, za test tabelu.

Medjutim, ako imas 85 brojaca i 85 kolona u tabeli za njih, to jeste problem. Zar ne mozes to da prerasporedis na ovaj oblik:

Tabela: OcitanjeBrojaca{Cas, BrojacID, Kumulativ}
Tabela: Brojac {BrojacID, Opis, Lokacija,....}

To je bolje nego Ocitanja{Cas,Brojac_1,Brojac_2,...Brojac_85} sto izgleda da imas.

Onda bi se dao napisati jedan jedini kveri, koji daje casovne potrosnje za sve brojace.

Dizajn baze i punjenje je stvar stranke. Inace je to uradjeno iz WinCC-ja.
Ako sam dobro razumio tvoj prijedlog, bi za jedan sat u tabelu Ocitanja upisao 85*60 = 5100 zapisa. Sada se upisuje 60 zapisa na sat.
Potrosnju racunam na formama i reportima. Podloga je jedna temp tabela koju punim sa jednim veeeeelikim queryjem po prije opisanom postupku.

Evo resenja kako je Zidar predlozio, s time sto sam dodao i BrojiloID tako da mozete ovim upitom dobiti za sva brojila...

Hvala lijepa. Zadnji query pokaze pravilan rezultat. Ipak to rijsenje mi u praksi ne pomaze jer polje kumulativa je jedno od 85 brojila. Problem je v dizajnu baze. Kao sto sam Zidaru odgovorio dizajn je takav zbog redukcije broja zapisa. Evo saljem tempTabelu (za jedan dan) sa svim brojilima pa probajte sta iskemijat.

Zoran me pretekao Sad sve radi korektno, svaka cast.

emol, Predlazem da uneses jos nekoliko brojila u tabelu TestTablea, u Zoranovom drugom resenju.

Ne brini sto ce biti 85*6==5100 zapisa. Accesu je mnogo lakse da radi sa uskom (malo kolona) a dugackom (mnogo rekorda) tabelom. Ako probas, videsec da tabela od 60 rekorda sa 85 kolona zauzima mnogo vise prostora na disku nego 4 kolone u 5100 zapisa. No, to je nevazno, disk prostor je jeftin, a ako se lepo indeksira pristup je mnogo brzi na uskim tabelama. Glavno ej da ako ikad budes morao da dodas jos jedno brojilo, neces morati da menjas niti tabelu niti kveri. Primacujes da za Zoranovo resenje treba najmanje 6 a mozda i 7 kverija. I ako u svih ovih 6-7 kverija budes imao po dve kolone za svaku od 85, nece biti dobro niti lako za pisanje.

Evo ti i moje resenje (ZD), ima samo 3 do 4 kverija, u principu isto kao sto je Zoran uradio, samo je UNION na pocetku umesto na kraju. Uploadovao sam i Zoranovo resenja, sa dodatim jos jednim brojilom, (ZE2) da vidis na sta sam mislio.

Vec sam dao cijelu temp tabelu u odgovoru Zoranu.
Oko dizajna baze bi rekao samo to da sam u pocetku predlagao kombinaciju dviju tabela ali je to bilo pretesko za covjeka koji je to radio iz WinCC-ja.

OK, razumeo sam. Neka tabele kakva je, ako tako zahteva WinCC. Jos uvek ima spasa. Mozes da napravis UNION query koji normalizuje tabelu, pa na to da primenis Zoranove kverije.

Ako imas jednu tabelu tblTempPodatki za svaki dan, nemas vise od jednog dana u toj tabeli, onda mozes da primenis ovo sto sam zakacio direktno. Ako imas vise dana, treba da u prethodnom koraku izfiltriras samo rekorda u tod danu. To je lako, dodacemo ako treba.


Poledaj NOVI QUERY TestTabela. Nazvao sam ga tako da bi Zoranovi kveriji radili i dalje. To je UNION o kome sam govorio. Ja sam napisao za 7 uredjaja, ti mozes ostatak. Ceo kveri moze da se napise za svih 85 uredjaja za nekoliko minuta, i brze uz pomoc Excela Ako imas problem da sastavis UNION, pomoci cemo.

Elem, evo ga resenje:

Sta da kazem? Svaka vam cast. Ko zna zna.
Za dnevni report punim temp tabelu za jedan dan, za druge po danima itd.
Pogledacu ovo sto si poslao pa javim.