Newsgroup: it.comp.appl.access
Titolo: File già in uso che invece non è in uso su applicazione condivisa (sfizioso, astenersi perditempo :-P)

Ho creato un applicativo che attualmente funziona con questa struttura:
FE che utilizza più BE diversi, BE1 e BE2
C'è un BE principale, BE1, che è sul PC A, poi ogni PC ha un BE secondario,
BE2, locale.
Sul PC A c'è un FE che quindi lavora in locale anche col BE principale BE1
Sul PC B c'è un altro FE che si collega via rete al BE1 e usa il suo BE2
locale.
Dal PC B apro l'applicativo e mi fermo alla prima maschera, che è solo una
maschera con il logo e pulsanti Apri-Chiudi, senza quindi alcun tentativo di
apertura di tabelle collegate.
Dal PC A, a questo punto, apro l'applicativo e passo alla maschera
successiva che è una specie di pulsantiera di funzioni. All'apertura di
questa maschera via vba eseguo dei controlli per verificare che ciascuna
delle tabelle collegate per ciascun BE sia correttamente collegata
altrimenti lancio la funzione di riallegamento tabelle. Per fare questo
semplicemente apro un recordset sulla tabella e gestisco eventuali errori.
Quando vado a testare la tabella del BE2, quindi il BE locale, mi dice che
il BE2 è già in uso e quindi non lo posso usare.
Allora:
1) il BE è locale, nessuno può utilizzarlo!
2) questa cosa succede solo se è già aperto l'altro FE remoto che comunque
non sta usando alcuna tabella, nè la sua locale nè la remota BE1 che non
c'entra nulla col DB segnalato in uso
3) Se entro prima col FE del PC A poi con quello del PC B il problema non si
presenta e non c'è mai alcun problema di conflitto anche lavorando in
concorrenza sulle tabelle del BE1 condiviso.
Teoricamente questa cosa non dovrebbe succedere, quindi
- o è un bug grosso come una casa
- o mi sfugge qualcosa di veramente subdolo
Qualche idea per testare il problema?
Antonio

Antonio Biso ha scritto:





Controllare che tutti i recordset usati all'apertura per testare i
collegamenti alle tabelle siano correttamente distrutti, anche se in
teoria non c'entrano niente.
Verificare se effettivamente c'è il .ldb associato al BE2, entrare nelle
Proprietà - Protezione - Avanzate - Proprietario e verificare chi lo ha
creato.
Namor
-- 
namor at inwind punto it
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 creato.
beh, il file non ha problemi di diritti, tant'è che in situazione normale lo
uso normalmente...
Antonio

 ha scritto nel messaggio
news:tgU7c.84179$Kc3.2...@twister2.libero.it...

Dalla situazione che hai descritto non mi stupisce che hai diverse
"reazioni" per diverse situazioni; hai il pcA che lavora in locale anche con
il BE1 che viene aperto o utilizzato dal pcB che è in rete. Hai provato a
mettere il BE1 in rete e creare una situazione paritaria per ogni pc? Si
presenta lo stesso il problema?
Ciao.
--
Sergio MAZZA

 Antonio
Non era per problemi di diritti. Se guardi chi è il proprietario dell'ldb
puoi capire chi è l'utente che ha aperto il mdb, e magari riesci a capire
se lo sta tenendo aperto un PC dalla rete o il PC locale.


Sergio MAZZA ha scritto:



Non è lì il problema. Io ho usato per mesi un FE che lavorava su 3 BE
sparsi su vari PC, per cui in ogni PC il FE aveva un BE locale e gli altri
in rete, e funzionava bene, come del resto dovrebbe teoricamente fare, a
patto di tenere ben aggiornati tutti i collegamenti delle tabelle.


 se lo sta tenendo aperto un PC dalla rete o il PC locale.
Però l'ldb non c'è quindi, come supponevo conoscendo la situazione, nessuno
sta usando quel mdb.
Quindi quel messaggio è assurdo!
Antonio

 Namor
Infatti...
Antonio

 Antonio
E se lo apri a mano da Access invece che aprire un recordset dal FE?


 E se lo apri a mano da Access invece che aprire un recordset dal FE?
Ah, già... dimenticavo di dire cosa ho provato:
apro la tabella: OK
Provo a mettere un punto di debug quindi ad aprire la maschera iniziale
invece di partire con l'avvio dell'applicativo e quindi a tracciare:
FUNZIONA TUTTO!!!!
Antonio

 Antonio
Quindi il codice funziona. 
Bene, allora passiamo nell'universo parallelo delle congetture:
Sarà colpa della velocità di esecuzione? Magari il primo openrecordset
apre il .ldb, e quando chiudi il recordset il sistema operativo non fa in
tempo ad eliminare il ldb prima dell'esecuzione del secondo openrecordset,
che trova il ldb bloccato dal S.O. (che lo sta cancellando) e ti dà errore.
Tutto ciò potrebbe avere senso se distruggi il recordset tra un
openrecordset e l'altro, sennò ovviamente no perchè il ldb resta aperto.


 Namor
Uhmmm...
A parte che il solo fatto che si apra l'ldb non dovrebbe bloccare tutto
l'mdb, e neanche una tabella, tant'è che io lavoro regolarmente in maniera
concorrente su record diversi della stessa tabella.
Comunque io la distruzione del recordset non la faccio perchè non ci arrivo
e però l'ldb non ci sta...
E poi perchè questa cosa succede solo se c'è l'altro FE remoto aperto?
Sigh...
Antonio