Newsgroup: it.comp.appl.access
Titolo: Considerazioni sullo strano comportamento delle transazioni...

 transazione?
Dopo aver fatto una prova mi autorispondo...
Diciamo subito che il risultato della prova mi ha lasciato un poco
perplesso...
Flusso di istruzioni:
1) inizio transazione
2) apro recordset A
3) modifico dei dati nel recordset A
4) updato A
5) chiudo recordset A
6) apro recordset B (che estrae gli stessi dati estratti in A)
7) verifico che i dati in B sono i dati aggiornati, quelli che avevo
modificato in A
8) modifico B
9) updato B
10) chiudo B
11) fine transazione
La cosa funziona bene... però mi lascia perplesso; infatti durante una
transazione mi aspettavo di NON poter accedere ai dati modificati nella
transazione stessa, in quanto le modifiche vengono scritte sul disco tutte
assieme.
Da quanto capisco, il fatto di poter o meno accedere ai dati aggiornati
durante una transazione dipende dal modo in cui vi si accede.
Ad esempio, nella stessa aplicazione che sto realizzando ho visto che se
durante una transazione aggiorno dei dati in una tabella da codice, usando
dei recordset, e dopo le modifiche uso questi dati con una query di
aggiornamento... vedo i dati NON aggiornati, li vedo come erano prima della
transazione.
Tuttavia non so se questo dipende dal fatto che i dati venivano estratti da
una funzione usata in una query, oppure dal fatto che la funzione in
questione risiedeva in un modulo diverso da quello nel quele avevo iniziato
la transazione e dentro essa richiamato la query.
Voi che ne pensate?
Io dovrò fare altre prove per chiarirmi le idee...
Ciao, Max

(.....)
Direi proprio di sě, e mi sembra coerente: il metodo begintrans inizia
la transazione dal momento in cui viene richiamato, indipendentemente
da ciň che č avvenuto prima; ciň vuol dire che tutte le operazioni di
modifica dei dati effettuate tra il richiamo di begintrans ed il
richiamo di committrans, e solo quelle, vengono considerate come una
unica istruzione di aggiornamento.
Quello che invece lascia perplesso me č il seguente comportamento:
' campo1 č chiave primaria per Tab
dim recset as recordset, ws as workspace
set recset =currentdb.openrecordset("Tab")
set ws = dbengine.workspaces(0)
ws.Begintrans
with recset
.addnew
![campo1]="pippo"
![campo2]="pluto"
.update
docmd.runsql "UPDATE Tab SET campo2 ='paperino' WHERE campo1='pippo' "
ws.committrans
set ws = nothing
recset.close
set recset=nothing
questo codice non funziona, nel senso che l'istruzione SQL non trova
record da aggiornare.
Perchč ?
Se invece dell'istruzione SQL uso
.findfirst "campo1='pippo' "
if .nomatch = false then
   .edit
   ![campo2]='paperino'
   .update
endif
allora funziona !
Vincenzo Turturro
---------------------------------------------------------
Se no diventiamo tutti **** dai portatili o peggio ancora 
provetti poeti fiorentini come vturturro.
(Cosě disse Ivan Lelli Ven 25 Aug 2000 09:34:52 +0200)
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.clavis.it/as400/
---------------------------------------------

 Perchè ?
Credo che la risposta sia stata data da Karl Donaubauer in risposta al
messaggio "Strano problema con insieme TableDefs" qualche giorno fa.
--
Silvio


 allora funziona !
Appunto... l'impressione che ho io è che se usi query SQL vedi i dati come
sono stati bloccati all'inizio della transizione (infatti non trova nulla da
aggiornare).
Mentre se usi i recordset vedi i dati NON bloccati, e potresti quindi
trovare record da aggiornare.
Strano...
Max

Perchè ?
Perche' l'oggetto docmd non supporta le transazioni.
Prova con currentdb.execute "update ecc.
--
Lorenzo Coronati
--
<<Ragazzi, sapete indicarmi una utility in 
internet che sia in grado di recuperare le 
password da un database access e da un system mdw?
intendevo, gratuita...>>
(Marco Tullio Bisoli, 27/04/2001)
--

 Prova con currentdb.execute "update ecc.
Però è assurdo.... sarebbe come dire "toh, questo sportello bancomat non
supporta la scheda magnetica, quindi decido io da quale conto scaricare"
Mah...
Max

supporta la scheda magnetica, quindi decido io da quale conto scaricare"
No. E' come dire "toh, questa vite a brugola non si svita
con un cacciavite a taglio, quindi la forzero' con un piede
di porco"
Quando basterebbe usare la brugola.
Non confondiamo: qui si tratta semplicemente di usare gli
strumenti giusti.


 strumenti giusti.
Ok, ma mi sembra un baco grosso come una casa avere in un DB "serio" degli
strumenti che non sfruttano le transazioni
Max

strumenti che non sfruttano le transazioni
No. :-)
(scusa, non voglio essere polemico, non sono azionista M$ e
non ho parenti interessati ;-P)
Access ha gli strumenti che sfruttano le transazioni.
E lo sai.
Access ha *anche* strumenti che non le supportano.
C'e' un'enormita' di utenti che le transazioni manco sa dove
stanno di casa, ai quali puo' andar bene un uso massiccio di
docmd, perche' e' facile da usare e fa' un po' di tutto.
Chi sviluppa professionalmente, invece, puo' utilizzare gli
strumenti piu' adatti.
IMHO, ovviusli.
p.s. Ne vuoi sapere un'altra forse peggiore di .runsql?
Docmd ha dei bellissimi metodi .transferdatabase e compagnia
che, manco a dirlo, non si accorgono se stai dentro una
transazione. La sfiga e' che non ci sono corrispondenti come
invece .execute, per cui ci si deve sbattere con creazione
di tabelle via tabledefs o con sql.
Qui si' si sente la mancanza di uno strumento idoneo...
:-|


 :-|
ARGH! :-|
Tra l'altro no tato che la transferspreadsheet in o2k SR1+SP2 è un po
bacata, ed in certi casi sputtana l'incolonnamento delle tabelle.
Più nello specifico: avevo una query a campi incrociati, certi valore erano
numeri, altri non esistevano, in o2K normale funzionava bene, in o2k
SR1+SP2... a schermo visualizza i dati giusti (la query) ma se la esporto in
un file XLS alcune celle vuote su alcune righe (non sempre) scompaiono... e
quindi le colonne non sono più incolonnate... ed ho divuto cambiare la query
per mettere degli 0 dove non c'era nulla.
Mah...
Max