Newsgroup: it.comp.lang.visual-basic
Titolo: un po di info su Db e rete (1)

salve
sto facendo un po di prove  su come gestire un DB con Access in rete...
ovvimente le prove sono tutte teoriche per il semplice motivo che non ho una
rete... ::))))
volevo chiedere una cosa. poiche il problema principale da gestire sono i
possibli conflitti tra utenti che modificano lo stesso record o record
"dipendenti" tra di loro , e poiche (soprattutto) non credo che faro mai
programmoni giganteschi per DB in rete, avevo pensato di "tagliare la testa
al toro", e di bloccare il record sul quale l'utente intervene in modifica.
il problrma è cheho letto che ADO "legge" i conflitti (mediante il metodo
Filter dell'oggetto Recordset) soltanto quando si usa il meotod update. io
volevo continuare a gestire le modifiche tramite sringhe SQL (UPDATE,
INSERT).
in pratica vorrei che il programma si accorga di quando un record è
semplicemente aperto, non importa se in lettura o scrittura.
dopo un'istruzoine del tipo
set rst=cnn.execute("SELECT * FROM XX WHERE Campo > 20")
, in pratica, se qualcuno prova ad aprire uno stesso record contenuto nel
recordset Rst, il programma manda un messaggio che dice "il record è
bloccato. lo puoi olo leggee e non modificare. continuo?"
il problema è che non so come individuare quando un recordset è gia aperto
da qualcun altro.
qualcuno puo aiutarmi?
graze
MarioH

 ho letto che ADO [...]
ADO? Sorry, ma allora non posso aiutarti...
Ciao
*Roby*


e allora perche illudermi con il miraggio di una risposta ??!!??!!??!!??!!
::)))))))))))))))
MarioH

 ::)))))))))))))))
Mezza risposta č meglio che niente ;-)
Comunque in linea di massimo l'approccio di bloccaggio del record per tuta
la durata dell'editing non č dei migliori. D'altra parte qual'č il problema
teorico che ti costringe a questo approccio?
Nel caso di un inserimento di record, fai compilare tutta la maschera e poi
apri il DB e ne salvi i dati.
Nel caso di cancellazione, devi solo eliminare il record
Il problema semmai e nella modifica, ma puoi usare l'approccio di salvare in
memoria i dati del record che stai editando, e prima di salvare le modifiche
controllare che non siano stati variati. In questo modo puoi evitare di
tenere aperto il record per tutto il tempo, e se il record dovesse risultare
modificato, chiedi all'utente se vuole sovrascrivere le modifiche oppure se
vuole vederle e rieseguire l'editing.
In ogni caso se devi fare l'update di piů record alla fine di un singolo
editing, usa le transazioni in modo da poter fare un rollback se non riesci
a salvare tutti i dati perché uno dei database č bloccato.
Usando questo approccio del minimo tempo di blocco, puoi addirittura
toglierti il lusso di fare il locking a livello di recordset invece che di
singolo record. Questo si dovrebbe poter fare anche con ADO, usando un
parametro in fase di apertura.
Coraggio. Dall'ultimo messaggio sui DB in rete č passato qualche mese. Se
continui cosě, entro un paio di anni dovresti diventare un esperto. ;-))
Ciao
*Roby*

 No. Anzi, a quanto mi risulta non si puň proprio sapere.
la butto lě..
dare uno sguardo al file .LDB?
--
Fibia "Sakamoto" FBI
E-mail: 
fibi...@hotmail.com
ICQ UIN 63586057
Sito Personale: 
http://www.geocities.com/fibiafbi
VB Simple: 
http://vbsimple.virtualave.net
Membro #26 delle Mitiche Brigate Takahashi sezione Sud

 ha scritto nel messaggio
news:9oml64$e4hg6$1...@ID-66902.news.dfncis.de...


 QUOTE
grazie, vado a vedere, e sepro che poi quel DLL sia facile da usare e possa
essere distribuita senza problemi
MarioH


è un problema mica tanto teorico... mi scoccio di fare cose troppo
complicate. ::))))
ho pensato di proedere anche in un altro modo, e credo che sia il piu
eficace.... udite udite... :
l'editing non lo faccio usando cio che ho caricato nel recordset, ma lo
faccio usando di olta in volta istruzioni SQL, quindi niente rst.update, o
rst.updatebatch, bensi solo istruzioni INSERT, UPDATE e DELETE.
questo mi permette di usare il recordset SOLO per leggere dei dati, e una
volta letti, finiscono non in memoria, (o non necessariamente in memoria),
bensi su una maschera (se ci entrano tutti) o da qualche alra parte (se non
ci entrano).
es:
carico una lista di articoli che rispondono ad un determinato parametro, e
li metto in una griglia, come righe. uan colonna "nascosta" poi mi contiene
l'ID di ogni singolo articolo...
una volta effettaa questa operazione, posso chiuere il recordset, che
chiunqe puo modificare.
nel caso vada ad effettuare una modifica su una riga, io prima controllo
(tramit l'ID) se il record esiste ancora (qualcuno potrebbe averlo
eliminato), poi magari faccio qualche altro controllo di routine, ma in
nessun caso tengo "aperto" un recordset.
finora, per i prog che ho realizzato (tutti monoutente) ho fatto sempre
cosi, e spero di riutilizzare la stessa "tecnica" anche per i multi
utente...
se poi dovessi vedere che non va, beh allora ovviamente usero la tua tecnica
di tnere in memoria i record aperti e di fare i controlli prima dell'update
o dell'updatebatch...
pero sai, quando uno si affeziona ad un metodo, poi è difficile
abbandonarlo... ::))))
grazie di tutto.
MarioH

 database.
Grazie!! Proprio una dritta coi fiocchi.
Ciao
*Roby*
P.S.
Chi è che diceva che in questo periodo il NG è poco interessante? ;-)