Newsgroup: it.comp.lang.visual-basic
Titolo: [ADO] Transazioni e multiutenza

Oddìo!
ho appena sperimentato una cosa con ADO (MDAC 2.7).
Nel mio programma ho una variabile globale chiamata CN (Adodb.Connection).
Per necessità a volte devo avviare delle transazioni (metodo BeginTrans)
Solo che...
    Quando apro la mia transazione sulla macchina A e tento di accedere a un 
qualsiasi record sulla macchina B la macchina B si pianta e la connessione 
va in TimeOut.
Se dalla macchina A chiudo la transazione la macchina B riprende ad andare 
normalmente...
... ergo
... ho smesso di utilizzare le transazioni!
Qualcuno di voi ha per caso cozzato con lo stesso problema?

 Qualcuno di voi ha per caso cozzato con lo stesso problema?
Quello che hai descritto non č un problema, č il motivo per il quale
esistono le transazioni.
Sta proprio in questo comportamento la loro utilitą ^^

Si ma cacchio mi si blocca tutto il database !!! 

Si ma cacchio mi si blocca tutto il database !!! 
"Tutto" il database o alcune tabelle del database?
Quanto dura la procedura?
E soprattutto, dove apri e dove chiudi la transazione?
Magari un po' di codice ...
Ciao!

Vabbé ci provo con uno schema
Sulla macchina A:
--- Form_Load()
|     BeginTrans
|
|   Faccio Faccio
|   Faccio
|
--- Form_Unload()
    Commit/Rollback
Nel mentre la macchina B se sta lavorando A (cioè se la macchina A ha 
caricato la Form Incriminata) va in TimeOut.
Spero di essere stato abbastanza chiaro :-) 

Spero di essere stato abbastanza chiaro :-) 
Spero di esserlo stato io ;-)
Ciao!

Comunque ho capito.
Ho capito che le transazioni non fanno per me...
...nel senso che io non ho bisogno di eseguire piů operazioni sul database 
in un brevissimo lasso di tempo ma nel mio caso l'utente "smanetta" e il 
risultato della sua smanettata va direttamente nel database.
Quando l'utente č convinto che la sua smanettata č OK, allora conferma le 
modifiche e nel mio caso avrei chiuso la transazione (in single user si puň 
fare tranquillamente).
Ne deduco quindi che dovrň utilizzare un altro modo (proverň usando delle 
classi). 

 single user si puň fare tranquillamente).
Naturalmente si; il database e' bloccato comunque ma nessun altro ci 
accede...
Le transazioni infatti non andrebbero usate in questo modo; lo scopo 
principale e' quello di permetterti delle operazioni coerenti sul database, 
da un lato evitando che possano essere "sporcati" i record che sei in 
procinto di aggiornare, dall'altro per permetterti di ripristinare uno stato 
congruente, con un semplice rollback, quando uno degli N step di 
aggiornamento dovesse essere annullato.
Come diceva ErPotenza tipicamente vengono attivate nel lasso di tempo che 
intercorre tra la conferma dell'operazione e il completamento effettivo del 
codice che lavora sul DB; quello che vuoi fare tu invece andrebbe affrontato 
diversamente:
- Se non puoi fare a meno di salvare immediatamente su DB quelle che sono 
ancora scelte temporanee dell'utente, che puo' decidere di annullare alla 
fine, devi tenere traccia di tutte le operazioni per poterle eseguire a 
ritroso se necessario (ottieni quindi un rollback "casereccio")
- Altrimenti puoi mantenere solo in memoria (classi, UDT, variabili "sfuse") 
i dati modificati e rimandare tutte le operazioni sul database solo in caso 
di conferma positiva
Ciao
-- 
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown 

di conferma positiva
Aggiungo soltanto ... recordset disconnessi.
Ciao!

 Ciao!
aggiungo soltanto....3tier...e "relativamente" campi un po più
tranquillo....fai gestire concorrenza e quant'altro da uno strato/server
fatto ad hoc....
NON fare l'errore mio ai primi progetti multi utente:
una soluzione multi-user NON è una Soluzione SingleUser * Npc !!!
...è proprio UN ALTRA soluzione!
;-)
-- 
Il Wodkino Nazionale è a : 
www.martek.it
Pagina Vb/Bestiario/Lamer Experience :
http://www.martek.it/go.asp?portamia=2
 New Entry nel
bestiario! :-)
---
Messaggio scannerizzato e certificato "Virus free" da AVG free edition.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.773 / Virus Database: 520 - Release Date: 05/10/2004