Kako izraditi Access bazu koju bi punio XML datotekama.

Na izvješću imam dvije čelije; Potrošnja starog vodomjera i druga je potrošnja novog;ubacio sam čeliju nazvanu Dug(=[StanjeStarog]+[StanjeNovog]) i kada npr. napišem u prvu čeliju 15 a u drugu 2 kao dug dobijem 152, a ne 17. U čemu grešim???
Čelije su bile Text format!!!

_{[Ovu poruku je menjao dzaga29 dana 27.03.2019. u 08:42 GMT+1]}

Možda nešto ovako: Dug =Val([StanjeStarog])+Val([StanjeNovog])


Po drugi put: ..... Najbolji način za ovakvu komunikaciju je da praviš novi manji primer u .accdb formatu, postaviš samo neophodan broj tabela formi i ostalih objekata. Tako ćeš brže naći nekog ko će rado da reši primer.

Dok praviš primer, često se desi da sam otkriješ rešenje.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Covek ne dodje na forum neko vreme, kad ono - resavaju vodomere. pohvalno za pokusaj, ali djavolski tesko da se uradi. Toliko tesko da nisam siguran da igde postoji dovoljno dobro reseno. Stari IMS sistemi (PDP racunari pre 40 godina) su to resavali u QBASICu, sa puno ucitavnja iz text datoteka i menjanja DAT blokova u programu (!!!) Tako je moj operater svakog meseca pravila po sto i vise izmena u programu Sta ces, baza nije bila relaciona. Danas sistemi mogu donekle da podrze relacionu teoriju, ali se deo teorije koji za ovo treba ne uci u skoli, pa tako iresenja, stalno blizu i stalno se izmaknu kad mislimo da smo stigli do kraja.

U cemu je problem? Problem je dinamicke prirode. Podaci se menjaju kroz vreme - doadju se nova ocitanja. Vodomeri menjaju status i lokaciju. Ako su ugradjeni, onda mora da se zna ko ce da plati ono sto se ocita. Ako su na opravci, nista se ne placa. Ako su na bazdarenju, opet se ne placa utrosak vode, placa se bazdarenje ako bazdarnica nije vasa. To strasno lici na one slucajeve koje smo nekad davno analizirali - osnovna sredstva (kod koga je kamion), biblioteka (kod koga je knjiga), rentanje automobila ili bilo cega drugoga, i slicno tome. Slicno, ali ne i isto, je malo komplikovanije. Ne malo, mnogo komplikovanije. Tacno 2 puta komplikovanije. Ako imate zivaca i strpljenja da ponovo prodjemo kroz isti pakao, samo za red velicine topliji, mogu tome da posvetim malo vremena, samo na nivou strukture baze. Forme i reporte cete lako razresiti ako dobro postavimo osnovu. Upozorenje, moguce je da neke zahteve necemo moci resiti na nivou strukture baze. Mozemo da resimo mnogo, ali ne sve U 'velikm' SQL sistemima moze malo dalje da se ode, ali ne mnogo dalje nego u Accesu.

Ako smo raspolezeni, kazite. Ako ne - nikom nista, zivi bili i puno uspeha u radu.

Zidar hvala bogu da si se javio! Prošlih par puta (Upravljanje investicionim projektima i Baza za vođenje djelatnosti Geodetske firme) bez tebe nebi napravio ništa, a ovako imam dvije baze koje se još koriste i nakon 5-6 godina. Ako si pročitao tekst u početku otvaranja ove teme radi se o tome da postojeći program želim prebaciti u Access jer od mog skromnog znanja u Accessu ipak nešto mogu. Program ću ti poslati kompletan sa učitanim podacima da sam vidiš da li što nedostaje. Što se naplate tiče o tom djelu ja trenutno nebi razmišljao, osim eventualno kasnije ubaciti i razgranati bazu. Prvenstveno moja je želja u onom tehničkom djelu (to je moj sektor) da imam uvid u sve - koliko imamo kakvih vodomjera, koji su na servisima, koliko ih ima da im je prošao rok i moraju u zamjenu. Baždarnicu više nemamo jjer je nerentabilna nego kupujemo dvije vrste vodomjera i to nove sa modulima i servisirane. Servisiran je onaj vodomjer koji ja dobijem sa ovjernim žigom i ugrađujem ga kao novog jedino uz malo novaca vodomjer kojem je prošao rok ja ga šaljem dobavljaču u zamjenu za servisirani. Broj vodomjera koji ja vratim i onaj koji dobijem nazad nemaju skoro nikakvu šansu da budu istog broja. Tako da sam čak razmišljao da kada mu dam status da je razdužen da ga brišem iz baze, ali mi problem radi arhiva izmjena jer ga tamo moram imati. Vidjet ćes u kodu za izmjenu da li je moguće da ga se obriše. Za ovaj prvi kontakt ovo je nadam se dovoljno!
U prilogu šaljem bazu, Pozdrav!
P.S. Zaboravio sam reči da ću dobiti datoteke očitanja i želim ih samo ubaciti u program (očitanje ću obivati ili u XML ili Excel datotekama

Pino pozdrava svima. Drago mi je da stari programi rade. Siguran sam da si ih unapredio od tada,pozdravljam i to. Pazi samo da jos uvek rade sa novijim verzijama Accessa.

Vodomeri, dakle. Ja godinama se kanim da napravim sam to, onako iz fazona, ali nema se vremena ni volje vise kao pre. Ovo je zato sjajna prilika da me nesto natera da se pomerim s mesta :-)

Da se razumemo, svi saveti koji su ti kolege dali ranije vaze i dalje. Ja cu da probam da razresim onaj dinamicki deo. Ako to uspe, onda ce verovatno neki saveti biti zastareli, ali to ne umanjuje njihovu vrednost ni malo. U ovom trenutku, to su najbolji saveti koje mozes dobiti, tacka.

Da predjemo na posao. Ovaj paragraf iz tcvog poslednjeg posat je skolski primer kako se projektni zadatak objasnjava u dve-tri recenice. Pomaze malo sto sam i ja proveo 10 godina u vodovodu, u dva, po pet godina i tamo sam naucio osnove o prikupljanju, upravljanju obradi podataka. Kad sam dosao u Kanadu, naucio sam MS Access, pa psle malo i SQL (verzija 6.5!) i onda su se kockice slozile...

Zahtev i opis problema: "Prvenstveno moja je želja u onom tehničkom djelu (to je moj sektor) da imam uvid u sve - koliko imamo kakvih vodomjera, koji su na servisima, koliko ih ima da im je prošao rok i moraju u zamjenu. Baždarnicu više nemamo jjer je nerentabilna nego kupujemo dvije vrste vodomjera i to nove sa modulima i servisirane. Servisiran je onaj vodomjer koji ja dobijem sa ovjernim žigom i ugrađujem ga kao novog jedino uz malo novaca vodomjer kojem je prošao rok ja ga šaljem dobavljaču u zamjenu za servisirani. Broj vodomjera koji ja vratim i onaj koji dobijem nazad nemaju skoro nikakvu šansu da budu istog broja. Tako da sam čak razmišljao da kada mu dam status da je razdužen da ga brišem iz baze, ali mi problem radi arhiva izmjena jer ga tamo moram imati. "

Odgovor:
-- koliko imamo kakvih vodomjera, => to ide u master tabelu Vodomeri (serijski (fabricki) broj, precnik, opseg merenja, rok trajanja, proizvodjac itd.)

-- koji su na servisima => za ovo ide potpuno nova tablica, PromenaStanjaVodomera, ili "Gde je moj vodomer" ((serijski (fabricki) broj, gde je/kod koga je, kad je otisao tamo gde je, koliko mu je bilo citanje u momentu promene mesta ili osobe koja zaduzuje vodomer)

-- koliko ih ima da im je prošao rok i moraju u zamjenu => odgovor leziu gledanju u master tabelu Vodomeri (rok trajanja?) i "Gde je moj vodomer", qury "Svi vodomeri koji su negde (bilo gde) i danasnji datum je veci ili jednak datumu 'Rok Trajanja' u master tabeli)

-- Baždarnicu više nemamo jer je nerentabilna => dobro je znati, inace bi to bilo jedno od mesta gde moze biti vodomer u nekom trenutku

-- Servisiran je onaj vodomjer koji ja dobijem sa ovjernim žigom i ugrađujem ga kao novog jedino uz malo novaca => to je tabela "Gde je moj vodomer". Kad ga kupis prvi put, lokacija/status je "dobijen od dobavljaca" na neki datum, cutanje brojila = xxxx. Kad ga ugradis negde, stanje/lokacija je "Neka Adresa", ne neki datum, citanje u tom trenutku. Kad mu dodje vreme za popravku/vracanje/bazdarenje, to su sve moguca stanja/lokacije, na neki datum, i imaju neko citanje.

-- Broj vodomjera koji ja vratim i onaj koji dobijem nazad nemaju skoro nikakvu šansu da budu istog broja => to nas ne sekira ni malo. Jednostavno ce neki vodomeri imati poslednje stanje/lokaciju "Vraceni dobavljacu". Ako se vrati bas isti taj nekad, dobice status "Dobavljac vratio popravljen vodomer" i odatle ponovo u upotrebu, i veliki ciklus zivota vodomera se nastavlja :-).

-- Tako da sam čak razmišljao da kada mu dam status da je razdužen da ga brišem iz baze, ali mi problem radi arhiva izmjena jer ga tamo moram imati. => nista ne smeta da vodovod ustane zauvek u statusu "Rzaduzen" il "Otpisan" ili "Izgubljen", "Unisten","Ukraden". Bar ce u bazi biti trag, kada se sta od toga desilo. Ne brisemo nista i sve se zna - svi srecni na kraju.

-- Naplata. Naka naplatu radi knjigovodstvo, tako i treba. Medjutim, ti i dalje moras da ocitavas stanja. Ne moras mozda da racunas i potrosnju kao razliku dva uzastopna stanja, ali da ih ocitas, to se mora. Tu ce opet pomoci tablica "Gde je moj vodomer". Upisaces nesto ovako "Vodomer [SerijskBroj", ocitan dana "NedkiDan", na lokaciji [NekaAdresa], procitana vrednost je [CitanjeVodomera]. Ako sva citanja upises u tabelu "Gde je moj vodomer", imas sve sto ti treba da izracunas i potrosnju, ili da staro inovo citanje posaljes u knjigovodstva, pa neka oni racunaju :-) jedino moras da vodis racuna da korisnik kome naplacujes vodu bude tacan. To mozes da vodis u tabeli "Gde je moj vodomer" ali je prekomplikovano, pa cemo to ostaviti van ove price.

-- Interesantni su slucajevi:
1) kad se promeni korisnik, a vodomer ostane isti => ocitas stanje u momentu promene i duzis prvok korisnika za naplatu razlike, a novom korisniku to je pocetno stanje
2) korisnik ostaje isti, ali se menja vodomer => opet ocitas staje starog vodomera, razliku od proslog citanja duzis na korisnika. Novo stanje starog vodomera = "Skinut" ili "Razduzen korisnik" ili "Vracen u magacin", pa odatle dalje kako bude. Korisniku (nije se promenio) se daje novi vodomer - stanje "Ugradjen na lokaciju..", pocetno stanje ono sto pise na vodomeru u momentu ugradnje.

Sve sto smo ispricali, stanja, lokacije, promene, zaduzenja vodi se u tabeli "Gde je moj vodomer". Jedan isti kod upravlja svim promenama. Stos je napraviti listu mogucih stanja i lokacija, tako da mozemo da pratimo sta se desava. Lista ne mora iz prve da bude kompletna i perfektna. Vremenom se mogu dodavati nova stanja (stara se ne mogu brisati, ali se mogu ignorisati kad vise nemaju svrhu) Pored liste mogucih stanja, potrebno je definisati dozvoljene promene stanja. To radimo sa dve tabele "Moguca Stanja" i "Dozvoljene Promene Stanja". Te dve tabele kontrolisu sta se i kako moze upisati u "Gde je moj vodomer". ZBog zakona relacione teorija, prvo moraju da se naprave "Moguca Stanja" i "Dozvoljene Promene".

Moguca stanja. Za pocetak, mozemo definisati nekoliko ociglednih stanja: Stigao od dobavljaca, Postavljen kod korisnika, Ocitan, Skinut, Poslat Dobavljacu, Otpisan. Stanja nisu izlistana ni u kakvom redoledu jer njihov odnos nije linearan niti jednosmeran. Tokom zivota, vodomer prolazi kroz razna stanja. Neki prelzi imaju smisla, a neki ne. Na primer,

Neki vodomer moze da ima sledeci zivotni put:
Put 1: (Stigao od dobavljaca -> Postavljen kod korisnika -> Ocitan -> Ocitan...-> Ocitan -> Skinut -> poslat Dobavljacu.)

Neki drugi moze da ima drugaciji put:
Put 2: (Stigao od dobavljaca -> Postavljen kod korisnika -> Ocitan -> Ocitan...-> Ocitan -> Doelejn nom korisniku" -> Ocitan..Ocitan-> Otpisan

Broj kombinacija je veliki, ali ne i beskonacan. Neki ljudi razumeju promene stanja bolje ako se to - nacrta. rtez predstavlja graf, matematicki objekat koji se satoji od cvorova i linija koj povezuu cvorove (grane grafa). Cvorovi grafa su stanja, a grane su linije koje spajaju stanja. Nas graf bi mogao da izgleda ovako:

Svaka strelica je prelaz iz stanja u stanje. Mozda neke ne trebaju, ili neka stanja ne trebaju, slobodno ih se moze ukloniti. Potrebne su dve tabele:
DozvoljenaStanja : {Stanje text(25) UNIQUE (Stanje) }
DozvoljenePromeneStanja: {StaroStanje text(25), NovoSTanje text(25)
, UNIQUE (StaroStanje,NovoStanje)
, FK_1 (StaroStanje) REFERENCES DozvoljenaStanja(Stanje)
, FK2_(NovoStanje) REFERENCES DozvoljenaStanja(Stanje)
}

Tabela GdeJeVodomer za pocetak neka izgleda ovako:
ZivotVodomera { Vodomertext (50) StaroStanje text(25), NovoStanje text(25)
, DatumStarogStanja DateTime, DatumNovogStanja DateTime
,StaroCitanje long integer,, NovoCitanje longI nteger,
, KoJeZaduzen text 255 -- ovde se upisuje ko duzi vdodmer posle ove promene
sva polja su NUY MULL - Required = Yes,
UNIQUE_1 (Vodomer, DatunNovogStanja),
FK1 (StaroStanje, NovoStanje) REFERENCES DozvoljenePromeneStanje (StaroStanje,NovoStanje)
}

Za pocetak, napravite ove tri tabele. Dodajte relationships za svaki FK koji smo naveli. Unesite neke podatke ovim redom: DozvoljenaStanja
, DozvoljenePromeneStanja (svaka strelica na dijagramu je promena stanja. Pocetni kar = StaroStanje, vrh strelice = NovoStanje.

Onda pazljivo pokusajte da unsete dv-tri reda za jedn vodomer. Primetite da je u svakom redu StaroStanje on sto je u prethodnom redu bilo novo stanje Isto vazi za DatumStarog i NovogStanja, i StaoCitanje -NovoCitanje. Za prvi rekord, stavite StaroStanje = NovoStanje, DatumStarogStanja = DatumNovogStanja, StaroCitanje = NovoCitanje. Logicno bi bilo da sve Staro.. za prvired bude NULL ali Access to ne dozvoljava. MS SQL dozvoljava i to donekle olaksava posao u T-SQL. Ali samo T-SQL, sve ostale variante SQL se ponasaju kao Access.

Dakle, unesete prvi red, gde je sve Staro jednako sve Novo. U sledeci red u kolone Staro.. prepisujete ono sto je u prethodnom redu bio u kolonama Novo. Pazite, lako se gresi. Dobra stvar je sto cemo za tu operaciju napisati tri linije koda i zaboraviti na to. Posle nekoliko redova, primeticete sistem koji se ponavlja, podaci iz rda u red isu u cik-cak. lep izgleda, ali sta to nama koristi? Prvo, ako iamma StaroCitanje i Novo u istom redu, mozemo lako da izracunamo potrosnju. drugo, Staro I NovoStanje mozemo da uporedimo sa dozvoljnim promenama i sprecimo nekoraktan unos. Ako je vodomer "Otpisan" on ne moze da se pojavi vise nigde, jer iz cvora "Otpisan" ne izlazi ni jedna strelica. Iz cbora "Citanje" moze se ici nazad u taj cvor. To je ono sto se ocekuje u normalnim uslovima - vodomer sedi u mestu i cita se svako malo. Zgodno, zar ne?

Zgodno, ali nje sigurno 100%. Zato nam trebaju jos neke constraints, da bi podaci bili uvek logicni, bez duplikata, bez besmislenih promena i bez nelogicnih citanja. Datum novog citanja mora biti veci nego datum starog citanja, ili bar jednak. KAd vodovod ide na opravku, ocitamo stanje kad smo ga skinuli. Kad se vrati, bice neko drugo citanje, jer su u radionici pomerili tockice i zupcanike. I niko nece tu razliku sda plati jer ce se iz tabele videti da se ta promena na brojcaniku desila u radionic.NovoCitanje ne moze nikako biti manje od starog. Obicno je novo citanje vece, ali ne pri svakoj promeni. Kad skinete vodomer, citanje ce biti isto. Kad se vodomer preokrene (br0jac predje odnekih 999,999,999 i postane 1,000,000,000 kazaljka stoji na nuli, 000,000,000 sto je daleko manje nego prethodno citanje. To se moze dozvoliti samo ako je prethodno citanje bilo - 999,999,999, cak i ako ga nismo zaista procitali. Skor sve situacije koje mozete zamisliti mogu se registrovati tacno i jednoznacno. menja se korisnik a vodomer stoji na mestu. "skinete" vodomer , i ponovo ga postavite sa novim "

To cemo psole vikenda. Za sada napravite tri tabele i unesite malo podataka, da steknete osecaj sta se stvarno desava.

Koliko sam te shvatio ja moram u potpunosti krenuti od početka, tj. sve ovo što sam napravio ne koristi ničemu. Znači da jednostavno podatke koje imam u firmi za daljinsko očitavanje sa bzom kupaca, vodomjera i drugog neću moći koristiti te da će se unos 10000 kupaca i vodomjera morati vršiti ručno ili se samo radi o tome da se postojeći program preuredi??? Ova druga varijanta bi mogla proći, ali uvjet je da mogu u program inportirati očitanja. Ja sam već počeo sa izradom tablica ali dok ne shvatim ovo prvo pitanje stvarno sam zbunjen. Ja znam da je moj postupak bio naopak - Učitao sam XML datoteke koje sam u Accessu povezao i dobio bazu. Da se treba proširiti to m je razumno, ali sve odbaciti i nanovo to mi je problem jer ovako nikada neću dovršiti.

Ne brini, nece ti propasti podaci niti ces morati da unosis rucno. Cujemo se posle vikenda.

Ja sam nešto pokušavao ali neide, kada budeš mogao javi se pa ćemo kreirati tablice, ali ono u vezi naplata povlačim jer je normalno da kada imam potrošnju da znam i vrijednost fakture. U prilogu ti šaljem cjenik da vidiš kako se formiraju cijene, a za njih ćemo morati složiti i tablice za izračune. Pozdrav!

Pogledao sam shemu tabela, i nije tako lose kao sto sam pomislio. Tablce su manje vise OK. Tablica Ocitanja je prilicno prljava. Nasao sam 96 vofomjera u Ocitanja kojih nema u Vodomjeri. To ne moze. Izvukao sam ih u posebnu tablicu, pa ti vidi da li ces ih uneti u Vodomjeri, ili ces ih odbaciti. Ince, tablica Ocitanja ima bas onu struktutu koju sam preporucio: (Vodomjer_BR, Datum_Prethodneog_Citanja, PrethodnaVrednost(citanje), DatumCitanja, Vrednost(citanja). To je glavno. Pocitio sam sto sam mogao iz Ocitanja da bih napravio kako u stvari treba da izgleda.

Tablica Ocitanja je ono sto dobijas od telemetrije. OK. Napravicu drugu tablecu, OcitanjaSredjena, sa slicnom strukturom i popunicu je iz tablice Ocitanja Svi rekordi u Ocitanja bice pretvoreni u dva rekorda, po jedan za prethodno i novo citanje. Dok ovo uradim doci cu do metoda ciscenja podataka. KAd uvezes novu telemetriju u tabelu Ocitaja, kao sto sad radis, pre nego prebacis podatke u OcitanjaSredjena moraces da transformises ulazne podatke, da odbacis neke koji bi bili duplikti neke koji nemaju smisla. Za sada, vrlo je mali broj onih koji treba da se zanemare jer su neupotrebljivi, obrisao sam samo dva rekorda iz Ocitanja. U pocetku ces nalaziti vodomere u Ocitanju koji nisu zavedeni u tabelu Vodomeri, vremenom ce toga biti sve manje, kad se ceo sistem uhoda. Njih zavedes prvo, pa onda upises ocitano stanje, kao prvi rekord za taj vodomer. Posle ce proces ici ovako:

1) Ucitaj telemetriju iz .XML fajla o tabelu Ocitanja (da li se staraocitanja brisu ili se doda neki atribut da znamo kad smo i sta dobili u YMX?)
2) Procesljaj podatke u Ocitanja - duplikati, napostojeci rekordi, pogresni podaci skroz - imaces kverije i za to, i vremenom ces neke i dodati, kad god se desi nesto sto se nikada pre nije desilo.
3) Ubaci podatke iz Ocitanja u Ocitanja Sredjens (imaces querije za to, koje mozes automatizopovati)

Mozda ces morati da dogovoris novu struktury XML fajla, da ti ne salju podatke koji ti nista ne znace ili samo smetaju. Kad jednom pocnes da unosis u tablicu OcitanjaSredjena, unosis samo Datum_Ocitanja i Vrijednos. Ono za prethodno citanje i prethodni datum citanja vec ces imati u tabeli. Ako ti i dalje salju prethodno ocitanje, moze se to iskoristiti da se proveri tacnost. jedino je jako vazno da se ne propusti neki unostelemetrije. Ove vrste tabela, OcitanjaSredjene, ne podnose dobro naknadno dodavanje redova negde u sredinu. Za svaki vodomer samo se dodaju podaci, dodavanje unazad je dosta tesko.Upadte unesenih piodataka je prakticno nemoguce, a brisanje po principu sve ili nista. To nisu lose stvari, jer se tako cuva kvalitet podataka. Ako bas nesto mora da se menja naknadno ili brise, to zasluzuje posebnu paznju. Pokazacemo kako se i to radi.

Samo malo vremena da postojecu tabelu Ocitanja prebacim u OcitanjaSredjena, i nadam se da necu propustiti da zapisem neki korak u pripremi podataka, d a bismo mogli da sagradimo kverije koji ce to posle sami da rade.

Sve u svemu, sve sto imasu bazi je OK, samo cemo dodati StanjeSredjeno i jos dve tabele da kontrolisemo gde se nalazi vodomer - skidanja, postavljanja, poravke, otpisivanja. Te stvari se rade pojedinacno, dok ocitavanja radis 'in bulk' kroz XML. Sta ces interesantnije nego to

Drago mi je da ovo što sam napravio nije tako loše. Što se tiče tbl. Vodomjeri mislim da ima hrpa bezveznih podataka koji mi uopće ne trebaju, a što se tiče tablice Očitanja ja sam je samo učitao i nisam je prerađivao, ali kod očitanja ja ću imati xls. datoteku sa samo datumom očitanja, brojem vodomjera i novim stanjem. Na temelju tih podataka ćemo složiti tablicu očitanja - što treba a što ne. Svakako bi želio imati nekakvu arhivu u slučaju nekih reklamacija i sl.
Zaboravio sam napisati, ali si mogao zaključiti; potrošaće djelimo u tri grupe i oni se prepoznaju po šifri Domačinstva šifra 01*, Kućni savjeti šifra 02* i po0duzeć šifra 04*; Domaćinstva očitavam kvartalno, a KS i poduzeća mjesećno.

"kod očitanja ja ću imati xls. datoteku sa samo datumom očitanja, brojem vodomjera i novim stanjem" Odlicno, to je upravo ono sto nam treba.

Mozes li malo da detaljnije objasnis postupak citanja. Da li cita cove - ocitac i upisuje ocitano stanje u neki uredjaj koji onda salje ocitanje u neki fajl (.XML?). Ili mozda ne cita covek, nego neka automatika ocita stanje, na zahtev ili u zadatom trenutku, pa ta ista automatika posalje podatke u onaj isti neki fajl (.XML?) iz prethodne recenice. Ili je ensto trece. sta god da je treba mi da znam
1. ko cita (covek ili kompjuter)
2. ko trnsferuje ocitane podatke (covek npr sa telefona, kompjuter )
3. gde se tacno salju ta ocitanja - sirovi podaci
4. da li se citaju svi vodomeri odjednom (to bi kompjuter uradio) ili u sitom danu, svi ili grupe u istom danu ili nekom kracem intervalu. Ako ces podatke o potrosnji koristiti kasnije za neke analize, dobro je da su sva citanja u nekom kratkom roku.

Od ovog inicijalnog XLS fajla mislim da cu moci da malo posredim podatke. U tabeli OcitanjaSredjeno (mozes joj promeniti ime slobodno, samo mi javi da znam) imacemo sve podatke o zivotnom putu vodomera prvi rekord za svaki vodomer ce biti ili datum nabavke ako se zna, ili datum ugradnje, po mogucstvu kad je prvi put ugradjen. taj rekord ce imati citanja = 0 ili neki broj, ako je nesto ocitano. Cini mi se da kad dodju od proizvodjaca vec imaju neko citanje, koje su dobili na bazdarenju. Sta god da je, nesto cemo da posredimo.

Ako se desi da se vodomer ugradi a da nije zaveden egde, u tablicu Vodomjeri u nasem slucaju, upis u OcitanjaSredjena nece proci. Zato je to prvi test kad dobijes XML fajl: ima li rekorda u XML za vodomere koji nisu u tablici Vodomjeri. Ako ima, moras da ih dodas u Vodomjeri. Ako to nije jednostavno, onda ih iskljuci iz dodavanja i dodaj samo one koje mozes, a 'nepostojece' resavas kasnije. Ako ima nekih koji nisu ocitani zato sto su pokvareni/uisteni/zatrpani/ukradeni/poplavljeni i slicno, to ce se uneti, verovatno sa citanjem NULL ili nesto tako, ili se proceni, to je stvar vase interne politke. Kveri za transfer iz XLS ce prepoznati koja ocitanja su prva za dati vodomer, to neces morati da brines.

Zavisno od toga kako XLS fajlovi dolaze, mozda je pametno dodati neki ID, koji ce biti ista za sve rekorde u dolazecem XLS fajlu. ID ne mora biti numericki, moze text ali ne predugacak - do 25 kraktera mozda. Tako ces samo da dodajes XLS fajlove u tabelu Ocitanja, iz koje ce neki proces da prebacuje podatke u OcitanjaSredjena. IZ Ocitanja Sredjena ces lako dobiti potrosenu vodu = Prethodna_Vrijednost - Vrijednost.

Ponovo, process ce biti sledeci:

1) Ocitanja su zapisana negde
2) Iz to 'negde' dobijamo XLS, kao Vodomer_ID, DatumCitanaj, Vrijednost, Ocitac(?), XLS_ID (?)
3) prebacimo XLS utabelu Ocitanja, onako kako je, no questions asked. To je rekord za ono sta smo dobili.
4) proverimo nezavedene vodomere - (postoji u Ocitanaj, ne postoji U vodomjer)
5) u XLS, svaki vodomjer se moze nalaziti tacno jednom - nema duplikata - bilo je samo jedno citanje, a ne dva ili vise. ako bas ima dva ili vise, pogledamo sta je u pitanju i donesemo odluku sta ce se raditi (Problem Solving, eh)
6) proverimo da li su podaci logicni (Vrijednost manja nego Prethodna_Vrijednost i slicno)
7) prebacimo podatke iz Ocitanja u OcitanjaSredjena.
Kad doje verme, generise se nalog za naplatu - query koji racuna potrosnju, broj dana i slicno. Taj se salje u naplatnu sluzbu, elektronski po mogucnosti, ko struturirani fajl, Access il Excel, moze i XLS, to zavisi od programa koji ce stampati racune. Nalog za naplatu se cuva u posbnoj tabeli, gde se samo dodaju rekordi, nikada se nista ne brise niti se menja.


Ovaj proces je stvar organizacije posle, kompjuter i baza podataka samo sluze da taj proces omoguce.

Sad, pokusaj da das odgovor na pitanja na pocetku, o tome ko i kako ocitava i salje podatke U sledecm koraku bi trebalo da posaljem strukturu dodatnih tabela i neke kverije za kontrolu ulaznog XML fajla i prebacivanje u OcitanjaSredjens.

MCentar je software za kreiranje baze, gdje isto kao i u Accessu stvorimo tbl. Kupci i tbl. Vodomjeri. Kada imamo kreirane dvije odvojene tablice moramo ih međusobno povezati i svakom kupcu "dodjeliti" njegov vodomjer. Tek tada smo spremni za rad na daljinskom očitanju. Sada u MCentru kreiramo obilaske, tj. rute kuda će se kretati djelatnici na očitanju i koje će vodomjere na toj ruti očitati. Tako kreirane obilaske preko USB kabela prebacimo na Ručno računalo za prikupljanje podataka i pošaljemo djelatnike na očitanja. Na terenu koristimo Bluetooth prijemnik koji uparujemo sa Ručnim računalom za prikupljanje podataka (tzv. dlanovnik) i krećemo u očitavanje po predviđenom obilasku. Nakon što se izvrše očitanja podatke skupljene preko ručnih računala za prikupljanje podataka pomoću USB kabela učitamo nazad u MCentar gdje ih analiziramo, kreiramo izvješća ili ih prebacujemo na daljnju obradu npr. u obračunsku jedinicu i sl. Dakle očitanja iz dlanovnika su datoteke sa datumom očitanja, brojem vodomjera i očitanom vrijednosti. Dakle samu tablicu očitanja koja će se vidjeti na formi sami čemo kreirati i netreba nikakva očitanja iz MCentra. Ja sam je samo učitao da bi mogao raditi na bazi...
U ptilogu ti šaljem kako izgleda oprema za očitanje koje ljudi nose na teren. Očitanja se sva obave u par dana, a što nije daljinski to ide sporije od vodomjera do vodomjera.

Hvala, mislim da sada bolje razumem.

Razumem da MCCEntar samo cuva citanja i izbacuje izvestajetipa "datum, ocitanje, prethodni datum, prethodno ocitanje", sto nije od malog znacaja. Sta treba Access da radi dalje od toga?

[quote]MCentar je software za kreiranje baze, gdje isto kao i u Accessu stvorimo tbl. Kupci i tbl. Vodomjeri. Kada imamo kreirane dvije odvojene tablice moramo ih međusobno povezati i svakom kupcu "dodjeliti" njegov vodomjer.[quote]
Ako tablice Vodomjeri, Kupci, KupciVodomjeri (ili nima ekvivalentne datoteke) postoje u sistemu MC, zasto nam to treba u zasebnom Access sitemu? Za neku dalju obradu i/ili analizu?


Znaci li ovo da se podaci u tablici Obilasci takodje nalaze u MCCentar, pa ih prebacujemo u drugu bazu, za analizu?



Ovo razumem kao: U kancelariji imamo po jedan USB za svakog ocitaca. U te USB upisemo rutu dodeljenu tom uredjaju (ocitacu).


Bluetooth se zakaci za dlanovik


Ovo razumem kao: Ocitac zavrsi ocitanja, bluetooth to upise u dlanovik Kad se vrati u kancelariju, ocitac spoju dlanovik i PC na kome je MCCentar jednim USB kablom, te se podaci prebace u MCCentar


Znaci li ovo da se podaci izvoze iz MCCentar u Access bazu, preko XLS fajla? Ako 'da', sta nameravamo da radimo u Access bazi analizu utroska vode ili nesto slicno? Podaci ce biti na dva mesta, da li to zelimo i koji je razlog?

Na početku sam napisao da je MCentar jedan i do njega ne mogu svi djelatnici. Npr. djelatnica u računovodstvu dobije "prepisanu" listu očitanja iz MCentra jer njoj lista u kojoj je samo broj vodomjera i novo stanje očitanja ništa ne vrijedi jer su izvješća iz MCentra toliko loša i sirova da se ništa ne vidi i onda ona to unaša ručno. Upravo zato ideja mi je bila napraviti Access bazu koju će moći koristiti svi. Zaboravimo MCentar, on će biti isključivo za punjenje "Dlanovnika" za unos novih kupaca i vodomjera koje ću update u Access, te meni za eventualnu kontrolu. Dakle osnov svega je Access i kako ćemo posložiti bazu, a nju ćemo puniti preko excel datoteke. Uostalom na mom prvom postu imaš backup koji sam izvukao iz MCentra kada sam počeo!
Dakle, u MCentru će biti baza koja će biti isključivo backup!!!!

OK, sad razumem. Vido sam prvi post i saljem zakacene dve varijante baze koja moze da se napravi na osnovu podataka koje si dostavio u XML fajlovima. Ovako:

1. Prvo sam otvorio prazan Excel pa svaki od .XML ucitao i pretvorio u obican Excel file.
2. Linkovao Excel files na praznu Access bazu (nikakve tabele nisu postojale)
3. Onda sam odradio kverije koji pocinju sa A,B,C,D => dobili smo Kupce, Vodomjere i veznu tabelu KupciVodomjeri.

4. Query E1_ReadoutsToOcitanja sve prekopira iz Readouts.XLS u novu tabelu - Ocitanja.
5. Zatim se izvrse E2, E3, E4. E3 i E4 kreiraju tabele sa borjevima vodomera koji ne bi trebalo da budu u tablici Ocitanja. Te dve tabele, _OcitanjeZaNepostojeciVodomjer i _OcitanjeZaVodomjerKojiNemaKupca sam spojio u kveri UNION_VdmBezKupca_NepostojiImaCitanje. Taj UNION kveri je osnova za DELETE FROM Ocitanja - E5.

Time smo sve podatke prebacili, ocitili NULL values i duplikate. Onda sam napravio Primarne kljuceve. Svi kljucevi su realne vrednosti, koj imas i u MCentar programu. Jedino sam u tabeli Ocitanja promenio ime Meetr u MeterText, da bi kveriji bili prostiji. I postavio sam relationships na kraju.

Zakacio sam dve verzije baze, Z01 i Z02. Jedina razlika je kako su relationships naravljeni. Jedna verzija zahteva da za svako citanje, ocitani vodomer postoji u tablici KupciVodomjeri. To je dobro ako hoces da ulovis koji su vodomjeri protavljeni bez da su uneseni u bazu. Druga verzija trazi da vodomer koji s eocitava postoji u tabeli Vodomjeri, ne mora da ima dodeljenog kupca. Ovo ti dozvoljava da ucitas prakticno sve u tablicu Ocitanja, a;i posle moras da proveris koji su se vodomeri provukli bez podataka o kupcima.

Ovo je samo baz koja na relativno jednostavan nacin omogucuje transfer podataka iz MCentar. Ako je to sto ti je trebalo - onda smo gotovi. U tom slucaju nemamo pracenje gde je koji vodomer i kom kupcu je dodeljen u kom momentu. Takve promene su spore i nisu masovne, pa se to moze kontrolisati i na druge non-database nacine. U tom slucaju ovo je osnova baze i kraj posla.

Ako hoces da pratis i te promene, onda se ova struktura moze nadgraditi bez velikih problema. Pregeldaj i proanaliziraj, pa odluci sta ces dalje.

Ići ćemo dalje, jer sam vidio neke nedorečenosti (npr. više Šifra kupca za isti vodomjer što ćemo morati rješiti kroz neku tabelu gdje od ukupnog očitanja uzima ili postotak ili neku drugu vrijednost - to ću morati tražiti u firmi da mi kažu kako obračunavaju), ali uz tvoj post ja nisam dobio ništa - niti Z01 niti Z02.
Pozdrav!

U prilogu ti šaljem datoteke očitanja koje ću dobivati ubuduće; pokušaj ih uvući u očitanja s tim da se najnovija očitanja slažu od vrha i da su vidljivi svi podaci i jačina signala i napomena. Datum očitanja je vidljiv samo u nazivu datoteke.Kada sm htjeo vidjeti za koji vodomjer imam veliku potrošnju imao sam problem sa učitavanjem filtera - na stranici vodomjeri dozvoljava mi samo sortiranje po abecedi, a ne i po broju vodomjera???

Ooops, nisam kliknuo na Upload posle izabiranja fajla. Zaboravi se vremenom kako se radi.. Zakacio sam sada, na prethodnu poruku, provereno :-)

Hvala ti za uzorke u poslednjoj poruci. Pregledacu, ocistiti podatke ako treba i dodati. Ne diraj nista tabele u Z01 i Z02. Ja cu ih menjati na mojoj strani dok ne dobijemo tacno sta nam treba.

Sto se tice vise kupaca na jedan vodmjer, to nije tesko. U tabeli KupciVodmjeri dodacemo kolonu PctZaNaplatu. Za vecinu vodomjera bice to 100%. Za one sa vise korisnika, upisace se neki procenti, moze i razliciti za svakog, ali da zbir bude 100%. Ako se deli ravnomerno potrosnja na sve korisnike, onda nam ne treba posebna kolona. U obracunu cemo podeliti svaku potrosnju sa brojem kupaca zakacenim za taj vodomjer.

Probacu da nesto uradim danas, ako ne onda u ponedeljak.

Pozdrav

Samo edna mala sigestija od moja strana
Go gledav ovaj MCentar i vo specifikacijata za nego pisuva deka raboti so MS SQL Server baza.
Dobro e da se vidi bazata od ovaj program i verovatno e mozno da se pravat i izmeni ili vo najmala raka da se prezemaat i azuriraat podatocite bez export vo Excel .

Potpis

Z34GAL

Obzirom da nemam što za radit dok ti ne posložiš tablice i relacije, ja sam želio malo uređivati forme, ali kada sam želio isprazniti bazu i importirati excelove datoteke koje sam prije exportirao na tbl. Vodomjeri došlo je do greške i pokazalo mi je poruku u prilogu. Da li sam pošemerio ključeve ili što !!! Očito dok se ne posloži baza nemam što ispravljati i unašati, a sve forme, upiti i reporti su za obrisati?
Molio bi te da koristiš nazive iz tbl. koje sam ja upisivao kako nebi morao mjenjati sve Querie, Forme i Reporte. Vidio sam da si u tbl. Kupci_Vodomjeri uvukao i Datum_ugradnje, ali onda mi na Queri poručue grešku da se radi o više polja Datum_ugradnje. Ajde da prvo posložimo bazu i onda napravimo Export/Import da sve funkcionira!!!
Pozdrav!


_{[Ovu poruku je menjao dzaga29 dana 07.04.2019. u 21:10 GMT+1]}