SELECT tblOperacije.IDOperacije, tblOperacije.IDProizvoda, tblOperacije.RB, tblOperacije.KTO_1, tblOperacije.RAD_MJ_1, tblOperacije.KTO_2, tblOperacije.RAD_MJ_2, IIf([kto_1]=[kto_2],1,0) AS ProvjerKto, IIf([Rad_mj_1]=[rad_mj_2],1,0) AS ProvjeraRadMj
FROM tblOperacije
WHERE (((IIf([kto_1]=[kto_2],1,0))=0)) OR (((IIf([Rad_mj_1]=[rad_mj_2],1,0))=0));

Ovo mi ne riješava problem

(((IIf([kto_1]=[kto_2],1,0))=0))

To je provjera za podatke iz istog reda, a meni treba provjeriti KTO_2 i RAD_MJ_2 sa KTO_1 i RAD_MJ_1 iz narednog reda

pmiroslav ima najinteresantniji posao na svetu

Napravio sam ti dva kverija, qrySledecaOperacija i qryPogresniRekordi. Prvi je osnovica za resenje, a drugi zadaje zavrsni udarac.

Tabela koju si dao u primeru, nema ni jedan los rekord, pa sam dodao jedan koji narusava pravilo, da bi testirao kveri.

Malo sam promenio i relationships, ono tvoje nije valjalo. Ne uzbudjuj se mnogo oko greske, tvoj problem izlazi iz 'obicnih' relacionih problema. Primer je specijalan i zahteva specijalan nacin resavanja, koji nije uvek bas najjasniji, takva je priroda posla, sta ces...
Dodao sam ti i 'table constraint' na tabelu tblOperacije. Videces kad otvoris tabelu u design modu i pogledas properties Validation Rule, tamo pise Not ([KTO_1]=[KTO_2] And [RAD_MJ_1]=[RAD_MJ_2])

Jedino sto ti nedostaje jeste nesto da spreci los unos. pretpostavljam da ces ovim kverijem da pronadjes sve lose podatke i da ih ispravis. Posle toga treba ti nesto da spreci pogresan unos ili pogresnu promenu. To nazalost ne moze bez programiranja. Ja trenutno radim nesto slicno, sa slicnom logikom, rekord zavisi od prethodnog, pa mozda nesto i smislim ovih dana. Moj posao je u MS SQL i tamo ce resenje biti drugacije, ali sa istom logikom. Ako nesto smislim, dopisacu odgovor.

Svaka cast kolega @Zidar na upitima a i na ispravci veza u bazi.

@pmiroslav, svojevremeno sam radio model za Tehnoloske postupke za Sojaprotein, iz vaseg primera i veza koje ste uspostavili cini mi se da je model podataka konfuzan. Iako ste izvukli samo ono sto Vam je bio problem prilozicu Vam model koji sam tada radio radi mozda eventualnog Vaseg unapredjenja.

Evo resen i taj problem...

Hvala na pomoći za sada. Još nisam stigao to primjeniti na mojoj bazi jer mi je ona na poslu, a danas ne radim.
Što se tiče sprečavanja pogrešnog unosa od toga je sve i počelo. Mislim da sam to rješio programski tako da mi se automatski upiše KTO_2 i RAD_MJ_2 u polja KTO_1 i RAD_MJ_1 u slijedečem rekordu. Međuti to mi ne radi kako treba jer ima dosta pogrešnih unosa u tablici koja je zapravo bila prenešena iz baze rađene u dBase-u (*.dbf format), a u tom programu nije bila rješena kontrola unosa.

Evo malo sam sam mozgao i mislim da sm uspio nešto sam napraviti.

Napravio am prvo qryBrojOperacija koji mi broji koliko operacija ima pojedini proizvod, a to zato da prvo eliminiram
proizvode sa samo jednom radnom operacijom jer mi oni nisu interesantni.

Zatim sam napravio dva querya:

qryProces_1 i qryProces_2 na temelju tablice PROCESOP u kojima eliminiram proizvode sa jednom operacijom.

Zatim imam zadnji Query qryProvjera gdje sa

Pogresni_KTO: IIf([KTO1]=[KTO2];0;1) i Pogresno_RM: IIf([RAD_MJE1]=[RAD_MJE2];0;1)

provjeravam pogrešne upisa.

Zahvaljujem Zidaru na ideji smjernici


Sada je još problem pošto am pronašao 667 pogrešnih rekorda kako ih ispraviti, a da se to ne mora raditi jedan po jedan ručno

_{[Ovu poruku je menjao pmiroslav dana 31.07.2010. u 14:20 GMT+1]}

Drago mi je da se bar nesto resilo :-) Preko vikenda ne gledam forum, a ovd eje bio produzeni viknd, nije se radilo u ponedeljaki tako...
Pogledacu Zoranov predlog za sprecavanje losih unosa i sta je Miroslav uradio na kraju.

Problem 'kako ispraviti 667 neispravnih unosa' jeset bolan i bilo bi lepo da se resi kverijem, ili u nekom malom broju koraka, svakako ne 667 pojedinacnih slucajeva. To bi moglo u principu, kad bismo znali tacno kakve su greske u pitanju, to jest kako tacno ti rekordi treba da izgledaju. A to znamo, a mozda i ne znamom ili abr nigd eu bazi ne pise kako treba d aizgledaju rekordi....

Pokusacu danas da pogledam pa cu se javiti.

U primjeru koji sam poslao u svom zadnjem postu postavio sam kompletnu tablicu o bojoj se ovdje radi. To je tablica PROCESOP i sadrži 40693 rekorda. Doduše radi veličine sam izbacio naka polja koja ovdje nisu bitna.
Polje "ID" odnosi sa na Ident proizvoda, a polje "BROJ_OP" je redni broj radne operacije.
Znači proizvod npr. kojem je ID = 2 radna operacija 1 radi se u radnoj jedinici unesenoj pod KTO1 i na radnom mjestu pod RAD_MJE1.
Kada se radna operacija 1 završi proizvod se šalje u radnu jedinicu unesenu pod KTO2 gdje će se raditi na radnom njestu pod RAD_MJE2.
Slijedeći zapis za ID=2 je radna operacija 2 gdje KTO1 i RAD_MJE1 moraju biti indentični kao KTO2 i RAD_MJE2 iz predhodnog rekorda.
Nadam se da sam bio jasan.

OK, uradicu ti to sutra, danas mi je kasno.

Zakacio sam fajl sa resenjem. Umesto da radis UPDATE, predlazem da nanovo napravis tabelu PROCESOP. Dao sam ti skup kverija koji dovode do nove tabele PROCESOP, nazvao sam je PROCESOP_ISPRAVAN .

Ovo su novi kveriji:

- qryKTO_2_RMJ_2_Next_OP = pokazuje sledeci RB_Operacije za posmatrani proizvod, osnova za sve ostalo

- qryKakoBiTrebalo = pokazuje kako bi trebalo da izgleda deo tabele PROCESOP za operacije koje imaju vise od jednog koraka

- PROCESOP_ISPRAVAN = ovo bi trebalo da postane make-table quey i da ta nova tabela zameni porojeci PROCESOP

Dva kverija koji dokazuu da PROCESOP ima 663 greske a d je PROCESOP_ISPRAVAN zaista OK :

- qryKakoBiTrebalo_i_PROCESOP => daje 663 rekorda. Kveri qryProvjera (qryProvjera WHERE zbir one dve kolone na kraju nije nula) daje 664 pogresna rekorda. Razlika je Operacija 39378, koja je ispravana, ali ne valja rekord pre nje, kojme nedostaje RAD_MJE_2, a ima ga u sledecem rekordu. Ovo kazuje da tabeli PROCESOP nedostaju Required properties za polja. Bas svako polje mora da ima Required= YES, da ne bi dolazilo do ovakvih gresaka.

- qryKakoBiTrebalo_i_PROCESOP_ISPRAVAN => ne vraca ni jedan rekord, jer su svi u redu. Ovo je malo pogresno, jer ne vidi onaj jedan koji qryProvjera vidi, to je zbog NULL. Je podsvesno en racunam sa NULL jer ih ne ocekujem, posto uvek postavim Required = Yes gde treba, bar se trudim.

U svakom slucaju, tvoj kveri qryProvjera radi potpuno OK, bolje nego moji kveriji - hvata vise gresaka. Mozes ga iskoristiti da sprecis los unos. Kad jednom ocistis tabelu od gresaka, ovaj Dcount mozes da stavis u BeforeUpdate na formi kroz koju unisi podatke u PROCESOP i to bi trebalo da spreci los unos:

IF dcount("id","qryProvjera","[Pogresni_KTO]+[Pogresno_RM]> 0") > 0 Cancel = TRUE


Evo, na kraju sam prrimetio, imas cak 10 rekorda gde RAD_MJE_2 ima NULL vrednost, a ne bi smelo. Popuni NULL vrednosti sa n/a ili sta vec treba da bude tamo, pa onda ponovi sve provere. NULL vrednosti mogu da uzrokuju da kveriji vracaju pogresan rezultat (kao sto se desilo mom kveriju, a izgleda i tvom, jer ima jos gresaka koje nismo videli)


Eto.

Poštovani kolega Zidar, hvala na trudu. Ovo će mi svakako pomoći da riješim svoj problem.
Međutim još uvjek ću imati dosta "ručnog rada" zbog toga što u staroj aplikaciji iz koje potjeće tablica "Procesop" nije bilo relacije između tablica "KONTA" i tablice "RadnaMjesta" tako da je postojala mogučnost da se upiše podatak za radno mjesto koje zapravo ne postoji u pridruženom kontu.
Sada kada sam napravio relacije Access neće da ih prihvati zbog netočnih podataka.
Kako je ovo baza koja je popunjavana godinama i jako je važna u firmi u kojoj radim, moram si dati truda.