Newsgroup: it.comp.appl.access
Titolo: COMMIT ?

Sono in questo tunnel da diversi giorni. Non dico la luce, ma se c'e'
qualcuno che ha almeno una pila da accendermi.... Anticipatamente 
grazie.
IN SINTESI: come posso costringere Access 97 ad ottenere la scrittura 
FISICA di un .Delete o .AddNew o .Update su disco PRIMA DI proseguire 
con altre istruzioni?
IN DETTAGLIO:  in una maschera di un FE ho:
- una casella lista di riepilogo ELENCO riempita in apertura da  
un'istruzione SQL nella ROWSOURCE, che estrae FROM ARCH;
- un bottone ELIMINA.
Al clicK su ELIMINA:
1. apro il recordset (la gia' citata tabella ARCH) del BE collegato (in
Workspace 0);
2. con SEEK rintraccio il record da eliminare (la riga selezionata su
ELENCO);
3. ne faccio il .delete;
5. chiudo archivio e BE;
6. ordino il REQUERY di ELENCO.
Questo e' il punto. Quando i due database (FE e BE) erano uniti in un 
unico MDB, tutto funzionava a meraviglia. Divisi e collegati, 
l'aggiornamento del recordset funziona ancora, ma NON il requery della 
lista di riepilogo: alcune volte continua a rimanere visibile la riga 
deletata, qualche volta effettivamente sparisce, altre
volte Access scrive "#Eliminato" sul tutte le colonne della riga.
In situazione analoga lo stesso mi succede con .AddNew e .Update.
Credo che dipenda dal fatto che il requery parte gia' quando il buffer 
del recordset (cache) non e' ancora scaricato su disco, nonostante le 
operazioni siano incluse in un blocco BeginTrans-CommitTrans e ad esso 
segua DBEngine.Idle dbRefreshCache.
Sull'Help vedo pure segnalata una costante dbFlushOSCacheWrites, pero' 
ne' il mio Access ne' il Baker mi dicono che esista.
Di nuovo,
Luca Nicolisi.
-------------------------------------------------------------
"Non c'e' nessun buon posto per un inceneritore"
Paul Connett
-- 
Posted from 62.11.85.143 by way of 
smtp3.libero.it
 [193.70.192.53] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

"
incene...@iol.it
" ha scritto nel messaggio ...
Credo che dipenda dal fatto che il requery parte gia' quando il buffer
del recordset (cache) non e' ancora scaricato su disco, nonostante le
operazioni siano incluse in un blocco BeginTrans-CommitTrans e ad esso
segua DBEngine.Idle dbRefreshCache.
Di solito risolvo problemi del genere proprio con refreshcache. Pero' lo
metterei prima del begin trans....e al limite ce ne butterei unl altro prima
del commit!
Saluti.
Luciano
(DOC)

>Di solito risolvo problemi del genere proprio con refreshcache. Pero' 
lo metterei prima del begin trans....e al limite ce ne butterei unl 
altro prima del commit! Saluti.Luciano(DOC)
Re: Ho apprezzato l'aiuto, pero' niente da fare, i risultati sono 
incostanti. 
Probabilmente la cache viene trasferita col dbRefreshCache, ma mentre 
la scrittura su disco remoto avviene (dipendendo nei tempi dallo 
"stress complessivo" del sistema al momento) il programma VBA va 
avanti, incontra il requery e trasporta su maschera quello che trova 
fin qui scritto, forse anche perche', sebbene il recordset sia lo 
stesso, viene citato in due modi diversi (con SQL nella requery, 
attraverso un puntatore Set nel corpo del programma).  
Che tu sappia, non c'e' nessun modo di sapere quando e' stata 
completata la scrittura fisica su disco (chesso', attraverso un'API di 
W95)?
O fermare il programma finche' l'operazione di scrittura fisica non sia 
completata?
Luca Nicolisi.
-------------------------------------------------------------
"Non c'e' nessun buon posto per un inceneritore"
Paul Connett
Precedente 06/05/01 :




Credo che dipenda dal fatto che il requery parte gia' quando il buffer 
del
recordset (cache) non e' ancora scaricato su disco, nonostante le 
operazioni
siano incluse in un blocco BeginTrans-CommitTrans e ad esso segua
DBEngine.Idle dbRefreshCache.
Sull'Help vedo pure segnalata una costante dbFlushOSCacheWrites, pero' 
ne'
il mio Access ne' il Baker mi dicono che esista.
-- 
Posted from 62.11.87.25 by way of 
smtp2.libero.it
 [193.70.192.52] 


Di solito risolvo problemi del genere proprio con refreshcache. Pero'
lo metterei prima del begin trans....e al limite ce ne butterei unl
altro prima del commit! Saluti.Luciano(DOC)
Re: Ho apprezzato l'aiuto, pero' niente da fare, i risultati sono
incostanti.
Probabilmente la cache viene trasferita col dbRefreshCache, ma mentre
la scrittura su disco remoto avviene (dipendendo nei tempi dallo
"stress complessivo" del sistema al momento) il programma VBA va
avanti, incontra il requery e trasporta su maschera quello che trova
fin qui scritto, forse anche perche', sebbene il recordset sia lo
stesso, viene citato in due modi diversi (con SQL nella requery,
attraverso un puntatore Set nel corpo del programma).
Che tu sappia, non c'e' nessun modo di sapere quando e' stata
completata la scrittura fisica su disco (chesso', attraverso un'API di
W95)?
O fermare il programma finche' l'operazione di scrittura fisica non sia
completata?
Luca Nicolisi.
Premessa: non ho seguito il thread originale visto il pochissimo tempo a disposizione in questi mesi
:-(
Prova a utilizzare il metodo IDLE (vedi help).
Ciao, warp

Prova a utilizzare il metodo IDLE (vedi help).
Sě, buonanotte :-D
Volevo dire, prova a usare il metodo IDLE senza ricorrere a transazioni ma con una semplice gestione
degli errori di multiutenza sui recordsets.
Ciao, warp

Premessa: non ho seguito il thread originale visto il pochissimo tempo 
a disposizione in questi mesi.
Prova a utilizzare il metodo IDLE (vedi help).
Volevo dire, prova a usare il metodo IDLE senza ricorrere a transazioni 
ma con una semplice gestione degli errori di multiutenza sui 
recordsets. Ciao, warp
- Cosa intendi con "semplice gestione degli errori di multiutenza"?
 
In quanto all'IDLE ripropongo il quesito:
----------------------------------------- 
IN SINTESI: come posso costringere Access 97 ad ottenere la scrittura 
FISICA di un .Delete o .AddNew o .Update su disco PRIMA DI proseguire 
con altre istruzioni?
IN DETTAGLIO:  in una maschera di un FE ho:
- una casella lista di riepilogo ELENCO riempita in apertura da
un'istruzione SQL nella ROWSOURCE, che estrae FROM ARCH;
- un bottone ELIMINA.
Al clicK su ELIMINA:
1. apro il recordset (la gia' citata tabella ARCH) del BE collegato (in
Workspace 0);
2. con SEEK rintraccio il record da eliminare (la riga selezionata su
ELENCO);
3. ne faccio il .delete;
5. chiudo archivio e BE;
6. ordino il REQUERY di ELENCO.
Questo e' il punto. Quando i due database (FE e BE) erano uniti in un 
unico MDB, tutto funzionava a meraviglia. Divisi e collegati, 
l'aggiornamento del recordset funziona ancora, ma NON il requery della 
lista di riepilogo: alcune volte continua a rimanere visibile la riga 
deletata, qualche volta effettivamente sparisce, altre
volte Access scrive "#Eliminato" sul tutte le colonne della riga .
In situazione analoga lo stesso mi succede con .AddNew e .Update.
Credo che dipenda dal fatto che il requery parte gia' quando il buffer 
del recordset (cache) non e' ancora scaricato del tutto su disco, 
nonostante le operazioni siano incluse in un blocco BeginTrans-
CommitTrans e ad esso segua DBEngine.Idle dbRefreshCache.
Sull'Help vedo pure segnalata una costante dbFlushOSCacheWrites, pero' 
ne' il mio Access ne' il Baker mi dicono che esista.
Di nuovo,
Luca Nicolisi
-------------------------------------------------------------
"Non c'e' nessun buon posto per un inceneritore"
Paul Connett
-- 
Posted from 62.11.88.204 by way of 
smtp2.libero.it
 [193.70.192.52] 


unico MDB, tutto funzionava a meraviglia.
Forse non c'entra niente, ma mi pare che il metodo seek non funzioni sulle
tabelle collegate.
ciao, Michele


sulle tabelle collegate.Ciao, Michele
FUNZIONA, tant'e' vero che alla fine il recordset viene aggiornato 
regolarmente. 
Solo che mentre sta avvenendo la scrittura su disco, il programma va 
avanti, praticamente in parallelo, incontra il requery del listbox del 
recordset e mi presenta quello che trova scritto al momento, che spesso 
e volentieri e' ancora incompleto. Per fare un altro esempio: se faccio 
un inserimento con rest.AddNew, lo "riempio" con rst.update, faccio 
DBEngine.Idle dbRefreshCache e/o, prima o dopo, la commit del blocco 
transazione (ma ho provato anche senza transazione) e quindi il REQUERY 
della listbox di rst, qualche volta mi appare addirittura una riga 
vuota (come se sull'operazione parallela di scrittura fossimo in quel 
momento all'AddNew). Questo e' almeno quanto ho rilevato. 
Dovrei essere in grado di stoppare il programma fintantoche' tutta 
l'operazione di scrittura su disco e' stata terminata. Ma come??
Luca Nicolisi
------------------------------------------------
"Non c'e' nessun buon posto per un inceneritore"
Paul Connett
-- 
Posted from 62.11.86.47 by way of 
smtp3.libero.it
 [193.70.192.53] 


FUNZIONA, tant'e' vero che alla fine il recordset viene aggiornato
regolarmente.
Solo che mentre sta avvenendo la scrittura su disco, il programma va
avanti, praticamente in parallelo, incontra il requery del listbox del
recordset e mi presenta quello che trova scritto al momento, che spesso
e volentieri e' ancora incompleto. Per fare un altro esempio: se faccio
un inserimento con rest.AddNew, lo "riempio" con rst.update, faccio
DBEngine.Idle dbRefreshCache e/o, prima o dopo, la commit del blocco
transazione (ma ho provato anche senza transazione) e quindi il REQUERY
della listbox di rst, qualche volta mi appare addirittura una riga
vuota (come se sull'operazione parallela di scrittura fossimo in quel
momento all'AddNew). Questo e' almeno quanto ho rilevato.
Dovrei essere in grado di stoppare il programma fintantoche' tutta
l'operazione di scrittura su disco e' stata terminata. Ma come??
Queste asincronie d'aggiornamento sono normali in rete (specialmente
trafficate), ma in generale non è un grosso problema.
Almeno, ho ricevuto qualche lamentela, ma poi si abituano ad aspettare :-)
A volte si risolve semplicemente usando un Msgbox "Aggiornamento concluso"
per esempio, prima del requery.
Se la cosa ti consola ho notato che il fenomeno si verifica anche con un
server Oracle (che beninteso non conosco, ma viene usato in un'azienda che
seguo per altre cose).
Ciao, Simone

Se la cosa ti consola ho notato che il fenomeno si verifica anche con 
un server Oracle... 
- Non mi consola affatto. Mi pare che tutto il mio lavoro sia stato 
vanificato. Mi prende una tal rabbia d'impotenza che devo trattenermi 
dal prendere il computer dove sta Access e scaraventarlo sul pavimento. 
Credo che mi verra' un'ulcera...
Ciao.
Luca Nicolisi
------------------------------------------------
"Non c'e' nessun buon posto per un inceneritore" 
Paul Connett
-- 
Posted from 62.11.87.97 by way of 
smtp2.libero.it
 [193.70.192.52] 


Bisogna usare Opendatabase. Maggiori info su 
www.sitocomune.com
, sezione
Tables.
