Newsgroup: it.comp.lang.visual-basic
Titolo: LOCK dei record in VB = MERDA !!!

 
z...@iol.it
  Ciao
Stefano Piersigilli
e-mail: 
webm...@stephensoftware.it

 [...] faccia cadere in miseria



Infatti, ma e' l'unico modo per far lavorare due o piu' utenti in
concorrenza.
Inoltre, anche Access stesso lavora cosi' (almeno Access 2.0 faceva cosi',
poi non ho piu' avuto il tempo ne' la voglia di rodermi il fegato...).
Se apri due sessioni (A e B) di Access sullo stesso DB, stessa tabella,
su A editi un record (non salvarlo)
su B lo cancelli (lo stesso record)
su A ti sposti su un altro record (update del record modificato)...
vedrai che ti viene fuori un bel "#cancellato#" su ogni campo del record...
Yes, hai modificato magari una 30a di campi e, quando vai a salvare... quel
simpaticone di Access ti dice che e' stato eliminato, perso, buttato via...
bello, eh?
Se invece vuoi stare tranquillo, ma praticamente lavorare in single-user,
usa la soluzione A) (lock pessimistico).
--
Roal Zanazzi
z...@iol.it



Un attimo. Stai usando i data controls per modificare dei records in
rete? E' una scelta a dir poco discutibile ed il motivo l'hai scoperto
da solo. Forse sarebbe meglio se usassi i controlli convenzionali e ti
scrivessi una normale routine di aggiornamento. Avresti sempre il
problema della consistenza dei dati (comunque risolvibile andando a
controllare i campi prima di scriverli) ma almeno i cicli di
edit/update durerebbero solo qualche millesimo di secondo. Per quanto
riguarda la modifica al codice di magazzino (o comunque alla chiave
primaria della tabella) io, di solito, non la consento. Al massimo
inserisco una funzione che copia i campi su un nuovo record con un
nuovo codice.
Mi dirai che questo non ti basta e che ti serve a tutti i costi una
LOCK/UNLOCK vera e propria a livello di record. Piacerebbe anche a me
ma non e' possibile, rassegnati (con questo non voglio assolutamente
difendere la strategia adottata da access perche' sotto questo punto
di vista fa veramente schifo).
Vorrei pero' capire un po' meglio che tipo di applicazione stai
sviluppando perche' non vorrei che tu stessi sparando ad una mosca con
un bazooka. Io ho appena fatto una applicazione di contabilita' e
magazzino con VB5(SP3) + DAO 3.5 e, con il metodo che ti ho sopra
descritto, non ho avuto problemi.
Ciao
shrike

 >
Salve a tutti.
Sono un utente abituale di icda e mi sento pesantemente tirato in causa
da questo thread. 
Non posso non dissentire dalle opinioni di Zanazzi, ogni post su icda
riguardo
le problematiche del Jet engine e` e sara` sempre estremamente gradito.
Certo che se qualcuno ha voglia di postare una roba del tipo "il jet e` una
vaccata !!"
se la puo` anche risparmiare xche` la cosa e` universalmente riconosciuta 
(x quanto Zanazzi pensi il contrario, ma pare proprio che lui posti sui
thread senza neppure
leggerli).
Non pensate neppure x un attimo di trovare un branco di pecoroni
adoranti Access e/o il Jet (sono 2 cose diverse, Zanazzi !) come ci
descrive
il buon Roal); come su questo ng sono presenti un sacco di validi
professionisti
che in gran parte utilizzano x lavoro anche altri strumenti di sviluppo,
molto +
produttivi di Access e/o VB + Jet, non "bambini idioti" come il Zanazzi ci
ha
sottilmente definito.
Riguardo gli "insulti" e/o gli sfottimenti la storia e` lunga e chiunque
puo`
andarsela a rileggere cominciando dal post di esordio del Zanazzi
sul Thread "Strategie di Blocco" (guarda caso in risposta ad un mio
precedente
post), e, purtroppo, pare non intenda esaurirsi.
Chiunque e` libero di farsi la propria opinione in merito, ma spero
vivamente che
questo post non finisca x bloccare un possibile interscambio tra i 2 ng.
Salutissimi.
 



Solo una precisazione: l'oggetto del messaggio l'ho scritto io Stefano
Piersigilli e non il
sig. Roal Zanazzi. Lui e' solo convenuto con  me sui limiti e sulla
sconvenienza di utilizzo
di un prodotto che (forse per la mia poco profonda conoscenza) non esito a
definire di
SOTTOSVILUPPO piuttosto che di SVILUPPO.
E' stato comunque uno sfogo, che gente che fa questo lavoro, penso possa
comprendere
senza nemmeno pensare lontanamente, che ci possa essere nessuna intenzione
molesta
volta a compremettere qualunque ti po di interscambio di informazioni ne sui NG
ne altrove.
P.S.
Un programmatore che compromette l'interscambio delle informazioni e' una
negazione
assurda ......peggio di .......un prete che bestemmia !!!!
Cordiali saluti
Stefano Piersigilli
--
Contact     : Stefano Piersigilli
Company     : StephenSoftware(R)
Address     : Via Ettore Paladini, 45-47-49
Zip         : 00149
City        : ROME
State       : ITALY
Tel.        : +39-6-5571648
Fax         : +39-6-5560638
Internet    : 
http://www.stephensoftware.it
Compuserve  : 106165,2472
Fingerprint : 08 C6 63 BC 79 93 C1 98  46 20 45 11 30 77 5F C9