Newsgroup: it.comp.lang.visual-basic
Titolo: non riesco a trovare info su multiutenza ???

Tutti i testi che ho disperatamente comprato per cercare di farmi una
cultura sulla
produzione di applicativi multiutenza ( ossia che accedano a lo stesso db da
piu'
postazioni) parlano di server Sql Oracle, WindowsNt.
Ma io ho visto molti applicativi utilizzare come server anche pc w98.
Io posseggo la ver. professional di vb6 e non la ent., ho letto da qualche
parte che
c'e' la possibilita' di usare anche il motore jet per accedere a un db in
multiutenza,
ma non capisco come gestire il problema di due utenti che accedno e
modificano
lo stesso record.
Ho letto anche di un file LDB, ma non riesco a trovare il modo di impiegarlo
per ottenere le informazioni che mi interessano.
Se qualcuno sa darmi qualche dritta lo ringrazio molto.
Sarei grato se la o le risposte mi venissero postate anche in email.
Ciao a tutti Jury

 ha scritto




jury ciao -- stai mettendo insieme cose diverse.
0. la versione di vb. io uso vb5pro, che consente l'accesso ai dati. la
enterprise consente la creazione di applicazioni client/server, tipiche
appunto di un'impresa (credo sia questo il senso di "enterprise"). di qui il
salto nel listino prezzi. sospetto che lo stesso sia rimasto in vb6.
1. il sistema operativo e il percorso
a parte i problemi di sicurezza, per quanto ne so puoi tranquillamente usare
un mdb su win 9x.
se "c:\doc\" la cartella in cui sta "pippo.mdb" su "pc1", "pc1" fara' da
server:
--> in pc1 (rete-proprieta') attiva la condivisione dei file e condividi la
cartella
per collegarti da pc2, lanciando l'exe scriverai qc tipo (in dao):
    dim db as database
    set db=opendatabase("\\pc1\doc\pippo.mdb")
mentre da pc1 stesso avrai
    set db=opendatabase("c:\doc\pippo.mdb")
e/o simili. fai un po' di prove.
nota win9x: se attivi la condivisione a livello di cartelle, e sei in una
rete di 100 utenti, ci saranno 98 probabili curiosi che cercheranno di
ravanare nell'mdb. non ti so dire come si possano gestire le pass di rete da
vb. non ho neanche guardato come funziona la condivisione a livello di
utente. per le pass degli mdb, scorri i messaggi del ng. viene chiesto e
risposto un messaggio ogni 5. -- cmq questi sono i problemi in linea di
massima.
2. il lock (italiano: blocco) dei record (schede, tuple, righe).
questo e' un problema teorico della multiutenza, risolto in modo diverso nei
vari dbms. non ti so dare indicazioni precise per testi o siti su cui
studiare la faccenda, che comunque in sintesi presenta problemi tipo:
2.1.
* utente1 apre un record in modifica
* utente2 apre lo stesso record, modifica, salva
* utente1 modifica e salva
* utente2 fa un refresh (aggiorna), ed essendo un signore si limita a dire
"ohibo' !! dove saranno finite le mie modifiche ?"
--> cioe' se non ci sono blocchi di sorta, vince chi salva per ultimo. prova
ad aprire due volte un txt con due sessioni diverse di blocco note, scrivi
"testo1" nella prima e "testo2" nella seconda, salva ora l'una ora l'altra,
apri il txt in una terza sessione, e vedi che succede.
2.2.
* utente1 vede un contatore a 100, ma e' imbranato
* utente2 fa un addnew presto e lesto
* utente1 fa un addnew anche lui, si aspetta 101 ma si trova 102
--> se il contatore gli serviva a qc (anche se al momento non saprei proprio
immaginare cosa, a parte un film con molti cuccioli e crudelia),
cipperimerlo.
il problema e' -- appunto -- innanzitutto teorico.
fisico, oserei dire. non ci possono essere due oggetti diversi
nello stesso spazio e nello stesso tempo :)
i possibili casini aumentano parecchio p.e.:
* al crescere del numero di utenti
* durante cicli in cui il programma aggiunge / modifica / elimina schede a
raffica.
strade possibili: p.e., quando utente1 modifica, nessun altro puo'
modificare (edit) il record. se utente2 ci prova, gli arriva un messaggio
"attendere prego. utente1 sta lavorando per voi". questo e' il blocco.
dato che usi access, da vari thread (c'e' una risposta di roal anche di
ieri, mi sembra) direi che solo access 2000 consenta il blocco a livello di
record. il 97 blocca una "pagina" di 2k. cioe' se hai una tabella con schede
di 1k l'una, quando fai un lock ne blocchi 2. se sono di 200 byte, ne
blocchi 10, ecc. -- non e' il massimo, le probabilita' che un utente si
trovi davanti a una scheda bloccata e si annoi salgono molto.
--> prova cercare lock pessimistico e ottimistico nell'help di dao ecc. --
non so se ci sia una soluzione ottimale e onnivalente.
hth, pal
--
andrea dot palazzi at tin dot it
free vb/sw: 
http://www.comune.modena.it/cittadini/apal/html/

 wrote in message 8dg9ql$qgf$1...@nslave1.tin.it...


io gestisco in questo modo:
non blocco mai il record corrente se non per salvare i dati nel rcord stesso
cioč quando un utente modifica il record lo fa solo localmente e con il
recordset.update va a salvare sul db e in una tabella user memorizzo la
variazione del db stesso (tipo: user1;modificato, user2;ok, user..; ok....).
ogni tot, con un timer, verifico la tabella user e se c'č qualche utente che
ha modificato il db, faccio il refresh dei recordset.
la cosa non forse ottimale ma dipende poi da quanti utenti devono lavorare
in contemporanea sul db e quanto c'č concorrenza sugli stessi record.
questo modo evita che un utente metta in modifica(recordset.edit o addnew)
un record e vada a bersi un caffč :))
se c'č bisogno di avere una risposta diretta sulla variazione di un record
da parte di altri utenti, non ho avuto altre idee al riguardo!!!! avanti
altri rinforzi, interessa anche a me!!!!
ciao a tutti
--
Ing. Venturelli Aldo
via Vittorio Emanuele, 12
25042 Borno -Bs-
E-mail: 
aldo...@coopcsc.it
