Newsgroup: it.comp.lang.visual-basic
Titolo: Bloccare access ad mdb

Sto sviluppando un programmino in vb6, il quale dovrebbe girare in rete e
mi trovo davanti ad un problema che non riesco a risolvere.
Quando registro un record, devo bloccare il record in scrittura agli altri
computer che utilizzanon lo stesso archivio (magari solo in lettura opp.
aspettando che possano a loro volta registrare).
ecco come ho certato di dare (anche cambiando i parametri in tutti i modi
possibili)
   Dim CnnDB   As ADODB.Connection
   Dim RsT     As ADODB.Recordset
 
 
    Set CnnDB = New ADODB.Connection
    On Error Resume Next
    With CnnDB
        .Provider = "Microsoft.Jet.OLEDB.4.0"
        .Mode = adModeShareExclusive
        .CursorLocation = adUseClient
        Do
            Err = 0
            CnnDB.Open Percorso
        Loop Until Err = 0
    End With
 
    Set RsT = New ADODB.Recordset
    RsT.Open MiaTabella, CnnDB, adOpenKeyset, adLockOptimistic, adCmdTable
    RsT.Find "Codice ='" + Codice + "'"
 
    If RsT.EOF Then
        RsT.AddNew
    end If
 
    RsT.Fields("Codice") = MioCodice
    RsT.Fields("Descrizione") = MiaDescrizione
    RsT.Update
ma: o non riesco ad aggiornare il database, o mi da errore quando eseguo
Update etc. tutto a seconda della proprietą mode che ho scelto.
Qualcuno mi sa aiutare??? .... per favore.
Grazie.
Se č tutto sbagliato ditemi come devo cambiare.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 lettura opp. aspettando che possano a loro volta registrare).
http://makeashorterlink.com/?Q2F625027
http://makeashorterlink.com/?N12723027

     RsT.Update
Ti dico subito che in Access la multiutenza con ADO funziona pochissimo,
forse non funziona
affatto. La vera multiutenza la gestisci con query appossitamente create per
la serializzazione delle transazioni  usando come base dati l'sql server.
Oltre questo devi anche fornire alle tue tabelle un campo di appoggio che
può essere benissimo un campo di tipo bit (0,1) che ti permette di lokkare
il record via software, ovvero il tuo programmino è in grado di sapere quali
sono i records lokkati da altre postazioni e quindi non prenderli in
considerazione per le query del caso. Ti conviene, inoltre, affrontare la
problematica del blocco pessimistico rispetto a quello ottimistico
utilizzato nella tua sequenza di codice. Fatto questo riesci a gestire più
utenti con un unica base dati sapendo con certezza che ogni utente lavora
nella sua area dati senza intralciare in alcun modo il lavoro degli altri.
Ciao
Francesco

 pochissimo, forse non funziona
wow, fortuna che quando ho fatto un programma in multiutenza usando access e
ado non ero al corrente di questa limitazione, se no forse non ci
riuscivo...
--
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

 riuscivo...
Oh sommo softwarista, perchč non spieghi a noi umili mortali in cosa
consisteva la tua multiutenza ???? In piů sarei felicissimo di sapere su
quante postazioni CONTEMPORANEE girava....grazie per avermi dedicato 10 dei
suoi preziosi secondi, Oh sommo softwarista....

 dedicato 10 dei suoi preziosi secondi, Oh sommo softwarista....
Francesco, intanto che (anch'io son curioso) attendiamo la risposta di
CSSoft alla tua richiesta, ti posso dire la mia, in relazione alle tue
affermazioni?
Io non credo (nè, specialmente dopo aver provato, ho mai creduto) che un
qualsiasi motore di database (compreso SQL Server e qualunque altro), pur
disponendo di transazioni realmente gestite, possa gestire la reale
concorrenza. Non perchè abbia dei buchi (che pure ha), ma perchè non è
praticamente gestibile, detto secco. Lo è solo logicamente e, come ben
sappiamo, nessun motore, nemmeno il più sofisticato, può immaginare la
logica del programmatore.
Sai come, qualche lustro fa, un linguaggio che ho avuto la fortuna di
utilizzare gestiva la concorrenza? Con le istruzioni Lock e Unlock, alle
quali occorreva fornire un numero. Il numero era chiaramente
gestito/inventato dal programmatore che doveva semplicemente (!) stare
attento a usare lo stesso numero quando logicamente (!) intendeva bloccare
la stessa zona logica, di qualunque genere (destinazione, ampiezza, etc.)
essa fosse. Io non ho più trovato un'istruzione del genere. Ho dovuto
inventarmela. Ancora oggi, certo, nella mia smisurata ignoranza, la ritengo
l'unica possibile. Io non credo ai lock automatici, nemmeno a quelli che
bloccano 1 o 4 records/settori/pagine, proprio e solo perchè sono fisici
(relativi a records, oltretutto dinamici in ambiente di concorrenza), mai
logici. Non ne faccio una colpa ai progettisti, ma non le uso perchè le ho
provate e NON funzionano, non possono funzionare. Alzerei il cappello a chi
dovesse introdurre la logica (sopra descritta) il Lock e Unlock, spartana e
di una semplicità incredibile, ma funzionale e, soprattutto, funzionante.
Non lo fanno, correggimi se sbaglio (sempre per mia ignoranza), perchè si
devono riempire la bocca con tecnologie avvenieristiche e inapplicabili
nella realtà che sarebbero paradossalmente invalidate dalla semplicità che,
da sempre, dovrebbe caratterizzare qualsiasi cosa, compresa l'informatica.
E allora che faccio? La logica la realizzo io e, se la rete non casca e
risponde, funziona. Nel contempo mi obbliga a rimettermi il cappello,
irrispettosamente, proprio davanti a quelli che si riempiono la bocca di
cose galattiche, ma grottesche, perchè non funzionanti.
Io, in tutta sincerità, non so se un progettista di software di base in M$,
una volta integrato nell'ambiente, sa e/o si preoccupa di che cosa
significhi creare una fattura in ambiente di multiutenza con aggiornamento
contestuale del magazzino. Non lo so, ma, spudoratamente, mi lancio in un
"no, non lo sa, nè se ne preoccupa". E, per certi versi, ha ragione di non
preoccuparsene. La quotidianità e l'esperienza ci insegna che certi
problemucoli li devono risolvere i programmatori e mi può star bene. Non mi
sta bene, proprio per niente, che mi si dica "questo motore gestisce la
concorrenza" perchè non è vero, non può essere vero, per nessun motore che
non abbia, sempre per esemplificare, un'esplicita (e, ovviamente,
correttamente gestita) istruzione di Lock da parametrizzare a mio (e non
suo) piacimento.

Quello che dici, forse è vero.
Ma vorrei sapere come gestisci un programma di gestione fatture con
scarico(contestuale) del magazzino?
Se puoi, puoi spiegarmelo? Visto che devo realizzare una cosa simile?
Grazie.
Confido nella tua risposta.


 Sergio

Dimmi come hai fatto.... grazie?
Aspetto dei suggerimenti


Sto aspettando dei suggerimenti, magari spezzoni di parti di codici.
NON MI ABBANDONATE


 scarico(contestuale) del magazzino?
In breve:
Ogni cosa che presume un aggiornamento deve farlo in tempo reale, ovvero il
più vicino possibile alla realtà dei fatti, quindi ogni volta che aggiungo
una riga a un documento che presume aggiornamenti (una bolla, più che una
fattura) ne aggiorno gli effetti ovunque, ogni volta che elimino una riga ne
devo stornare gli effetti ovunque e ogni volta che vario una riga ne devo
stornare gli effetti ovunque con le informazioni precedenti e riaggiornarli
ovunque con le nuove informazioni.
Ovviamente in ogni fase di aggiornamento/storno occorre bloccare l'articolo
interessato (in modo che nessuno possa modificarne i contenuti), caricarne i
dati attuali e "freschi", procedere con l'aggiornamento/storno, riscrivere i
dati e sbloccarlo.

 suo) piacimento.
Allora....vediamo un pň di rimettere in ordine le idee. Non credere che la
gestione della concorrenza significhi che CONTEMPORANEAMENTE si possano fare
due o piů operazioni. La concorrenza non č altro che una corretta gestione
delle operazioni da fare sui dati. Un buon motore di database non fa altro
che mettere in serie le query che gli arrivano da tutti i punti remoti di
una rete e eseguirli sequenzialmente. E' vero il discorso che il sistema di
lockaggio lo deve gestire un programmatore via software e non affidarsi piů
di tanto alla gestione dei database ma se ti č ben chiaro il famoso "Teorema
dei semafori" riuscirai a comprendere il tuo sfogo.
Ciao
Francesco

 "Teorema dei semafori" riuscirai a comprendere il tuo sfogo.
Il mio sfogo? ;-)
Certo che ho ben chiaro il teorema dei semafori (si vedano i due link citati
nel primo post di risposta) e, anche da quel che scrivi, è altrettanto ben
chiaro che una database non può bloccare una zona logica che ho in mente io
quando le istruzioni che gli passo riguardano altre zone, per esempio un
contatore mentre scrivo la testata di una fattura. ;-)

 contatore mentre scrivo la testata di una fattura. ;-)
Allora, facciamo cosě. Spiegami quello che vorresti fare e vediamo se posso
darti una mano.
Ciao
Francesco

[*Francesco Sorrentino* = 
f.sorrent...@tin.it
 in
news:bulmsp$4l9$
1...@newsreader.mailgate.org
] ha scritto:

Ehm, veramente io non avrei problemi. Sono solo intervenuto rispondendo a
Romina e poi a te.

 Romina e poi a te.
Forse mi hai frainteso. Volevo solo sapere ciò che intendi nelle parti che
ho evidenziato.
Ciao

 Forse mi hai frainteso.
Forse non ti sei spiegato.
Volevo solo sapere ciò che intendi nelle parti che ho evidenziato.
Che adesso hai evidenziato.
Immagina di dovre creare una fattura, numerandola in modo univoco e
progressivo. Immagina anche che 2 o 20 postazioni possano farlo. Non basta,
con un solo comando SQL, recuperare il contatore, incrementarlo, riscriverlo
ed assegnarlo alla fattura. Occorre essere certi che il contatore resti
bloccato in modo esclusivo affinchè possa essere incrementato e riscritto
dalla postazione che stta creando la fattura. Le altre postazioni, che
stanno tentando di fare la stessa cosa, devono fermarsi e attendere la
disponibilità del contatore, non della fattura, in modo di disporre di un
numero aggiornato e gestibile come prima descritto.
In altre parole, un comando SQL che dovesse permettere tutto questo, a me
non garantisce che il blocco venga rispettato, allora ne faccio
tranquillamente a meno e la logica di blocco me la implemento io, come
voglio io.


Il tuo discorso è perfettamente chiaro. Nel tuo caso, sai benissimo che
finchè non dai la conferma alla stampa della fattura, del numero progressivo
te ne frega ben poco, quindi guardando la cosa dal lato opposto io farei
anche 50 fatture su 50 postazioni diverse, tanto il numero progressivo lo
calcolo alla fine quando la query memorizza tutto sul database. A quel punto
è il db a serializzare la sequenza di registrazione fatture e da un
progressivo per ognuna di loro.
Ciao

 di registrazione fatture e da un progressivo per ognuna di loro.
Sì se si tratta di un Long autoincrementante, non se si tratta di un mio
numeratore (alfanumerico, distinto per sezionale e per sigla, magari per
fatture e note accredito). No, non un long autoincrementante.
PS: Mi è capitato di vedere qualche db con due long autoincrementanti
uguali. No, non erano chiave d'indice...
Come vedi, la concorrenza non è gestita, non può esserlo, mai e con nessun
motore.

 voglio io.
Forse non comrendo a fondo il problema, ma le transazioni servono 
proprio a questo.
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 motore.
Con l'esempio che ti ho fatto potrai notare che la concorrenza la gestisce
il database.
Ciao

 proprio a questo.
Per quello che ne so (non le uso, non le userò mai perchè sono balle,
specialmente se con un solo programma devi gestire db di tipo diverso,
alcuni che le gestiscono, altri solo per finta...) una transazione serve a
... "non far niente" finchè non gli dai l'ok (Commit...). Ora, se anche
fosse, chi mi garantisce che il contatore che devo bloccare non venga
letto/gestito da altri? Una transazione blocca gli altri? Non mi pare
proprio.
E se devo dare un'istruzione che riguarda una tabella mentre devo tenerne
bloccata un'altra come faccio / quale motore lo può immaginare?
Il motore è un esecutore. Non pensa.

 gestisce il database.
No, insisto. Un database può prevedere comportamenti minimali, non può
gestire perchè vorrebbe dire essere intelligente.

 Il motore è un esecutore. Non pensa.
Infatti il motore non deve immaginare niente, sei tu che gli dici quali
dati saranno modificati dalla transazione, e questo provvederà a
bloccarli.


 gestire perchè vorrebbe dire essere intelligente.
Non si tratta di intelligenza, ma di testardaggine. Se lokki SQL in modalità
pessimista "lato server" e lo lasci per un pò vedrai con i tuoi occhi che da
un'altra postazione in rete non riuscirai più a tirare nessuna query.
Ciao

 bloccarli.
Io non li voglio modificare, non subito, non ora, ma fra un secondo, un
minuto o mai...
Nel frattempo (tutto il tepo che io decido) voglio che tutto resti com'è
eppur che quel record (o quell'intero file) sia bloccato per tutti. Senza,
senza, senza fare modifiche sul database che non siano quelle per
registrare, su tabelle apposite, il blocco. Posso? Voglio!

 tirare nessuna query.
Ci proverò, ma non credo che una "Select * From Tabella" si neghi a nessuno.
Un "Update" forse sì...

 registrare, su tabelle apposite, il blocco. Posso? Voglio!
Certo, i dati rimangono bloccati dall'inizio della transazione alla fine
della stessa, che duri un millisecondo o 100 anni (timeout
-modificabili- a parte), per quanto dubito gli altri utenti possano
apprezzare la cosa...


 e non "lato client"
PS:
-In DAO + Access, perchč ADO č penosamente lento.
-Un pelo piů indietro: In Professional Basic e MSDOS con Novell Personal
Netware.
-Con la mia logica, non quella di un qualsiasi provider o motore, che abbia
una qualsiasi logica, per davvero o per finta...

 Un "Update" forse sì...
Provaci e poi fammi sapere.
Ciao

 una qualsiasi logica, per davvero o per finta...
Scusa ma non sono daccordo. ADO o DAO sono oggetti di connessione e per
quanto complessi o semplici č il database che ti da la lentezza delle
operazioni. Io cmq uso ADO + SQL Server e ti dico che vado come una scheggia
anche lanciando query contemporanee da 30 postazioni in lan.
Ciao

 lan.
Volevo dire che ADO fa cagare.

[*Francesco Sorrentino* = 
f.sorrent...@tin.it
 in
news:bum0ns$jac$
1...@newsreader.mailgate.org
] ha scritto:

Ho provato.
Ho aperto un recordset (Select * From Tabella) su un Access 97, con ADO 2.7,
cursore lato server, adOpenStatic e adLockPessimistic.
Per estrema diligenza, ho avviato un'altra sessione di VB con lo stesso
programma e ho aperto lo stesso recordset. Non si è bloccato nulla. Ho il
recordset.
Ora chiedo: rispetto a quel che s'è detto (!), dove sbaglio?

 Ora chiedo: rispetto a quel che s'č detto (!), dove sbaglio?
Sul fatto che stai parlando di Access97 e non SQL Server.
Ciao
Francesco

 Volevo dire che ADO fa cagare.
Ho capito ma è una tua opinione. I miei applicativi girano tutti su ADO e
non ho mai avuto problemi.
Ciao
Francesco

 Io mi ci trovo benissimo
E' lento come la fame.

 Sul fatto che stai parlando di Access97 e non SQL Server.
Cià, scommettiamo con SQL Server?

 riuscivo...
Confermo:
ADO più Access XP (ma anche Oracle o SQL server): si può gestire (quindi
impostare / rilevare / togliere ) il lock su singolo record, con sblocco
automatico in caso di interruzione di funzionamento del programma
(spegnimento accidentale/crash/quant'altro).
Se si usa Access 97 non si può fare il lock sul singolo record, ma sulla
pagina, quindi con limiti evidenti.
Sconsiglio fortemente l'uso di flag casarecci: prima o poi saltano e bisogna
intervenire a mano o spiegare all'utente come sbloccare la situazione.
Per il resto, il lock, se impostato in esclusività (zona critica) impedisce
fisicamente la scrittura di due utenti sullo stesso oggetto
(pratica/fattura/quant'altro), pur lasciando la possibilità di lettura
(stampe/riepiloghi).
termoPilucco.

 E' lento come la fame.
None...a me va forte credimi

 Cià, scommettiamo con SQL Server?
Cosa vuoi scommettere ?

[*Francesco Sorrentino* = 
f.sorrent...@tin.it
 in
news:bum73j$td8$
1...@newsreader.mailgate.org
] ha scritto:

Senti, facciamo che rileggi quali sono le condizioni (Select * From Tabella,
con lato server, adlockpessimistic e adopenstatic) e poi decidi tu. Io ho
già provato, anche con SQL Server... Viceversa spiegati meglio.

 ha scritto nel messaggio
news:bum9dk$je8ip$1...@ID-174464.news.uni-berlin.de...

Pardon se mi intrometto.
Eseguo con 
ADO.NET
 il blocco della tabella anche in lettura, in SQL Server.
In considerazione che uso istruzioni SQL, presumo che il tutto è ripetibile
in ADO.
Sono costretto a utilizzare le transazioni perchè 
ADO.NET
 lavora in
disconnesso.
Se interessa posso mostrare la sequenza.
Ave
giuseppeD

 disconnesso.
Guarda che anche ADO lavora in disconnesso e lo fa, a  mio modo di vedere,
in maniera egregia. Credo che questo tipo di lavorazione sia molto
performante quandodevi lavorare su una quantità alta di record e con un gran
numero di postazioni, anche perchè il server si affatica poco.
Ciauz
Francesco

 ha scritto nel messaggio
news:buo955$hl4$1...@newsreader.mailgate.org...

Con ADO posso scegliere,
con 
ADO.NET
 potrò scegliere dalla prossima versione del Framework.
Il blocco della tabella è frazione di decimo di secondo.
Quindi se ho anche una decina di accessi al minuto alla tabella contatore,
per essere sicuro del numero univoco, la blocco in lettura e scrittura.
Di prestazioni, mi sembra che perdo pochino.
Ave
giuseppeD