Verovatno postoji način da se obradi i takva vrsta greške, ali svejedno mislim da nije dobra ideja da se tako vrši update baze.
Access u takvom slučaju mora da sa udaljenog servera, preko spore internet veze, na klijenski računar svuče željene recorde, da ih promeni, i vrati nazad, a za sve to vreme slogovi moraju biti zaključani (lock) za ažuriranje...
Mnogo stvari tako može poći naopako, i rizik je veliki, iako možda na prvi pogled može da izgleda da sve lepo radi.

Rešenje je naravno Stored Procedura i njeno pozivanje iz Accessa. Onda se sve odvija na Serveru i to je sasvim druga priča.
Ja nemam iskustva sa MySQL bazom, ali primere za MS SQL možeš naći u ranijim porukama na forumu.

Hvala na pomoci, ali problem i dalje ostaje...taj trenutak vracanja podaka na server.
Int. konekcija je brza i stabilna...ovo je sta ako...tj, predvidjen problem. Simulirao sam vestacki prekid. Preuzeo podake obradi...poceo da vracam i onda u trenutku prekid. Sistemska greska koju nemogu da obradim...Stoji alert prozor, a masina u pozadini radi. Dok je ne primetim i ponistim , transfer ce biti u prekidu.

Ne mogu da ti pomognem konkretno oko Accessa, ali je princip u ovakvim slučajevima da se na neki način promeni Severity level greške. Našao sam nešto gulajući, ali ne znam da li se ovo odnosi na tvoj slučaj

Sad mi je sinula jedna ideja...da na izvrsavam automatski UPDATE pozivom Query-a, nego da iz koda radim azuriranje preko DAO. Da na taj nacin vratim kontrolu greske na nivo procedure,koda, pa da pokusam obradu greske odatle.

Pokušaj da meriš vreme trajanja transakcije i da posle zadatog vremena
postaviš kontrolno pitanje Nastavljate DA-NE i ako nema odgovora
preduzmi podrazumevanu akciju. I sve stavi u klasičnu transakciju koja
mora uspešno dase obavi inače vraćaš sve u stanje pre početka transakcije

Hvala svima. Resio sam problem...proradio kliker :)
Resio update kroz klasican kod, a ne kroz gotov QUERY, tako da imam kontrolu desavanja i mogucnost obrade i greske.