Pretpostavljam da radis export ne iport kako si naveo.
Pri eksportovanju ako se desi da postoji isti naziv objekta pojavit ce se greska.
Nesto drugo iz ovoga je tesko zakljuciti.

ne, radim import. imam glavni MDB fajl (aplikacija) i fajlove sa podacima (klijent1, klijent2 itd.). radim tako što kad otvorim Aplikacija.mdb se bira korisnik sa kojim se radi, a onda se linkuju tabele iz npr. klijent1.mdb i importuju izveštaji. znam za tu foru sa istim imenom, ali u tom slučaju on preimenuje importovani objekat. pa ako sam u MDB fajlu imao izveštaj "Faktura" i importujem neki istog naziva Access ga preimenuje u "Faktura (1)". ne dolazi do konflikta.

e sad, ja sam danas par sati mozgao i čačkao i na kraju sam uspeo da rešim problem. iz nekog razloga Access temp fajlove (koji nastaju u toku importovanja) ne čuva u podrazumevanoj lokaciji (username\local setttings\temp) već u root-u drajva. naravno, u root-u limited useri nemaju puna prava pristupa i onda može samo da kreira TMP fajlove, ali ne može da ih menja i briše. nije mi jasno zbog čega se ovo dešava, pogotovo što on u grešci koju prijavljuje eksplicitno piše da ne može da pristupi fajlu u "local settings" folderu. na kraju sam limited userima dao puna prava pristupa u root i sve je proradilo.

nekome će ovo možda biti korisno, jer sam ja sasvim slučajno otkrio gde je greška. mada mi i dalje nije jasno zašto brlja po root-u kad postoji TEMP koji služi za to.

Ovo je malo neobican nacin rada. Obicno se ima jedan fajl sa podacima i gomila aplikacija koje se kace na taj fajl. Razlog je upravo da bi se izbegli problemi koje imas i nepotreban rad
Kako napredujes sa razvojem sistema, sve ces se vise zapetljavati i sve ces teze resavati probleme koji nailaze. Zasto ne razmislis da li bi nekako moglo da se stave svi podaci u jenu bazu, pa sve ovo sto radis sa importovanjem i linkovanjem jednostavno otpada?

Skoro sam negde rekao da uglavnom dobri programeri cine gresku 'nedovoljno dobar dizajn baze'. Neko sa 1/10 tvojih programerskih spoosbnosti uradio bi znatno bolji sistem, ako bi baza (back end = tabele) bila pravilno projektovana. Ti, sa svojim znanjem programiranja, mogao bi da napravis chudo od sistema, ukoliko ne bi gubio vreme na resavanje problema koji ne bi trebali ni da postoje.

Hvala ti na odgovoru. :)

Ideju o ovakvom razdvanju front/back end sam dobio upravo ovde na ES. Postavio sam temu gde me je zanimalo šta ljudi rade sa problemom gde imaju jednu knjigovodstvenu aplikaciju i potrebu da rade sa više klijenata. Npr. imaš knjigovodstveni biro, gde se podaci za svako preduzeće čuvaju odvojeno, jer mi je bitna tajnost podataka. Ali za svako preduzeće je front end isti.

Znam da je najbolje da se baza projektuje ovako kako si ti to opisao, ali u ovom slučaju mi to očigledno ne odgovara. Pošto je aplikacija već bila postavljena kad sam potegao ovo pitanje, najjednostavnije rešenje je bilo baš ovo: jedan front end sa logikom, više back end-a sa tabelama. Jedini problem je ostao oko tih izveštaja, jer su neki specifični za pojedine klijente. To ostaje još da se reši programski, ali trenutno nemam vremena za to, pa sam ubacio ovo "zakrpljeno" rešenje sa importovanjem.

Inače, ova aplikacije je pisana namenski (naručena je za jednog klijenta) i ono što je sigurno je da će ostati u Access okruženju, pa nema potrebe da se komplikuje logika. Ako bih sve držao u jednoj tabeli, morao bih da u celu aplikaciju ubacujem informaciju o trenutnom korisniku, da uvedem prava pristupa itd. a čini mi se da bi to bio (u ovom slučaju) nepotreban napor.

Sto se mora, mora se. Hvala ti na iskustvu koje si podelio s nama.