Velcità transazioni

[joke2k]

Sto provando ad inserire in un'applicazione VBScript/ASP le transazioni e ho riscontrato alcuni problemi.
Il database è Access ed è bello pieno 9Mb.
L'applicazione deve funzionare in locale, con due pc collegati e IIS.

I primi problemi erano sorti quando aprivo contemporaneamente nei due pc la connessione al database (file già in uso), e ho risolto con un "on error resume next".
Poi tutto sembra funzionare, ma quando dai due pc provo a scrivere nel db,
Uno dei due pc, va avanti, l'altro... rimane a caricare.. per Troppo Tempo, e poi ovviamente si perde l'informazione da inserire nel db...
Infatti non credo faccia il conn.RollBack (vedi sotto), poichè non trovo nulla dentro la variabile "errore".

/* Quel Troppo Tempo sarebbe fallimentare per quanto mi riguarda..*/
Colpa delle connessioni non chiuse (che ci si scorda di solito)?
Colpa di access? Dell'eccessivo peso (9 mb è tanto?)?

Per gestire le transazioni ho usato questo codice ovunque ci sia richiesta scrittura (UPDATE, DELETE,INSERT) nel db.

Grazie per l'aiuto.

Set conn= Server.CreateObject("ADODB.Connection")
conn.Open "Provider = Microsoft.Jet.OLEDB.4.0; Data Source = "& Server.MapPath("gestione.mdb")
sqlDO = "INSERT INTO DettOrdini (Nome) VALUES ("& nome &")"
conn.BeginTrans
conn.execute(sqlDO)
If conn.Errors.Count > 0 Then
	' errori: annullo tutto
	conn.RollBackTrans
	errore = "Errore :
"& conn.Errors.Item(0) & ".Clicca Indietro e riprova."
Else
	' tutto bene, porto avanti e concludo la transazione
	conn.CommitTrans			  	
End If

[agenti]

scusa l'ignoranza , ma perchè hai adottato le transazioni ?

che vantaggi ti da ?

[joke2k]

... se entrambi i pc chiedono l'accesso in scrittura nel database... da errore su uno dei due, e pensavo che con le transazioni questo potesse essere gestito... quantomento avvertendo che l'operazione non era stata completata.
Forse ho capito male io, l'uso che ne deve essere fatto....



Come posso fare altrimenti?

grazie per la risposta.

[agenti]

credo che access sia limitato nell'uso contemporaneo di scrittura... direi che non è quasi in grado...


ti converrebbe usare mysql o postgresql in locale.

[joke2k]

Se qualcuno mi sa confermare questa limitatezza di access, effettuerò una conversione in Mysql.
Giusto per chiarire: dov'è che risulta essere necessario utilizzare le transazioni per accedere in scrittura al database?
Grazie

[agenti]

il limite in scrittura di access è cosa ben risaputa....


per questo vanno in voga db come mysqlsql e postgresql e interbase.


cmq leggi qui.

In bocca al lupo.

link

p.s. non ho mai sentito che per superare il rpobelma di scrittura contemporanea si dovesse utilizzare ms transaction.

Ciao.

[optime]

scrittura 'in contemporanea' de che? scusate, ma io voglio proprio vedere due client di access (di qualunque db!) che fanno 'sta cosa *in contemporanea*. le transazioni, poi, si utilizzano per tutt'altro, non per questa favola della contemporaneità...

[joke2k]

Ho già chiesto prima in che caso si usano le transazioni, ammettendo la mia ignoranza in materia.
Per quanto riguarda la contemporaneetà, indendo che mi posiziono su due pc e clicco quasi contemporaneamente sul submit, e per un caso o per un altro... uno dei due pc va avanti l'altro... no.

Se gentilmente puoi essere poco più prolisso e illuminarmi su transazioni, accessi e scrittura contemporanee...

grazie

[optime]

prolisserò come da richiesta

1. le transazioni si usano di solito quando si vuole garantire una *serie* di update. essenzialmente, se una delle mille operazioni che bisogna compiere fallisce, tutto torna come prima. facciamo un esempio: debbo aggiornare un listino, ma solo per certi articoli, prendendo i dati da un altro db. Come prima cosa metto gli articoli da aggiornare in stand-by, leggo l'altro db, faccio certe elaborazioni, e poi finalmente posso aggiornare il listino, e quindi togliere gli articoli dallo stand-by. Immaginiamo che per un motovo o per l'altro si verifichi un errore nell'elaborazione: se non sono sotto transazione, gli articoli restano in stand-by (perché l'operazione che li toglierebbe dallo stand-by sta DOPO l'errore, e quindi non si arriverà mai ad eseguirla); se invece sono sotto transazione, scatta il rollback e tutto torna come prima.

2. la contemporaneità... io inserisco un ordine, tu inserisci un ordine. io faccio click su submit, tu fai click su submit. al server uno dei due click arriva prima dell'altro. PER FORZA. Quello che arriva prima viene trattato prima, poi l'altro. La contemporaneità come vedi non esiste. Poi ci potranno essere dei casi particolari - spiega eventualmente il tuo.

prolissai abbastanza?

[joke2k]

La tua prolissità è abbastanza soddisfacente...

quindi, per capire se ho afferrato:
Se devo fare più UPDATE,INSERT e DELETE in serie.. senza interferenze, devo usare le transazioni.

Tornando al mio problema ... abbiamo stabilito che i due Submit non possono essere contemporanei, ma quando sono troppo vinici, uno viene processato l'altro rimane in attesa, e si perde il dato da inserire.
E' semplicemente access?