Newsgroup: it.comp.lang.visual-basic
Titolo: [?]Ado.Net Ditemi che ho torto

Salve a tutti.
Da un testo leggo:
"..... presenta un nuovo tipo di accesso ai dati DISCONNESSO chiamato
ADO.NET
"
Vocabolario Italiano: Disconnettere = "Separare parti tra loro connesse"
Da un testo su ADO (no 
ADO.NET
)
La disconnessione di un Recordset richiede due passaggi:
1- La proprietà CursorLocation del recordset deve essere impostata al valore
adUseCliente
2- Una volta che il Recordset è stato popolato con i dati del server, la
proprietà ActiveConnection del Recordset deve essere
impostata a Nothing.
E la proprietà pessimistica ? (Ripeto , conosco poco 
ADO.NET
 e spero di
essere sommerso da un mare di "non hai capito nulla")
Per avere il pessimistico la connessione deve essere lato server.
Per bloccare quel record devo essere collegate a quel record in modo
CONNESSO.
Es.
Ho una somma di 50
A aggiunge 100 , legge e fa 50 + 100 =150
B aggiunge 50 , legge e fa 50 + 50 =100
A fa Update. Mi trovo 150
B fa Update. Mi trovo 100
in cassa mi trovo 100 e NO 200.
Solo il pessimistico mi blocca dopo la prima lettura ; il secondo , se si
collega nello stesso istante , riprova per alcuni
secondi fino al sblocco , legge il nuovo valore e fa l' Update.
Ricordo di una dichiarazione , in una conferenza dimostazione su .NET della
Microsoft , dell'evangelista di Bill$
"... occorre abituare ed educare lo sviluppatore ad operare in modalità
disconnessa......."
E se ho collegati al server una decina di pc o anche meno.
Le licenze le pago ? Si
"Ma la connessione lato server costa in risorse."
E se voglio spendere un miliardo di euro in Ram , a te che importa ?
Occorre formare un comitato per la libera scelta della connesione ad un
server ?
Ragazzi ditemi che non ho capito nulla.
giuseppeD

Non ho letto tutto il tuo post, comunque si, 
ado.net
non utilizza oggetti lato server, ma solo lato client
quindi disconnessi.
Stanno implementando i lato server ... quando
li rilascieranno chi lo sà, ma forse è meglio così.
Ciao Andrea


Non , cosě non č meglio.
Leggi per intero il post e poi ne parliamo.
giuseppeD

Ragazzi ditemi che non ho capito nulla.
Il lavoro sta cambiando, non c'e' piu' solo il gestionale che gira in locale,
e per il quale persino Access puo' essere considerato un database.
C'e' anche l' applicazione che accetta connessioni da remoto (anche migliaia
di chilometri) ed usa interfaccia web: quale lock pensi di mettere su connessioni
che magari viaggiano su 56K o meno?
-- 
ciao, hal

 in cassa mi trovo 100 e NO 200.
[cut]
aspe, forse non ho capito la logica, ma non dovrebbe essere?:
ho una somma di 50 scritta in un record
a legge il record, lo trova libero e lo blocca (con flag o altro). legge 50
e fa 50 + 100 = 150
b legge il record, lo trova bloccato, aspetta.
a fa update, mi trovo 150. a sblocca il record.
b rilegge il record, lo trova libero e lo blocca. legge 150 e fa 150 + 50 =
200
b fa update, mi trovo 200. b sblocca il record.
mi sa che si sta parlando proprio di altre cose, l'ho buttata li'.
ciao, g.

 b fa update, mi trovo 200. b sblocca il record.
e per sicurezza abiliterei anche un timeout che dopo 60secondi liberi il
record


Devo riflettere.
Una prima impressione è che si stanno dedicando tutte le risorse per le
applicazioni via Web , non considerando che alcuni cambiamenti indeboliscono
i sistemi Client-Server "tradizionali".
giuseppeD

 ha scritto nel messaggio
Se mi trovo lato Server ed uso il blocco pessimistico , non ho necessità di
utilizzare nessun flag.
Pensa tutto ADO a bloccare e sbloccare.
Se trovo il record bloccato , ed un secondo tenta di leggere il sistema mi
mette in attesa per alcuni secondi e riprova in continuazione fino allo
sblocco.
Consideriamo che il blocco avviene per una frazione di secondo; la pausa
(perciò il tempo concesso al secondo) generalmente è impostata dai 10 ai 20
sec.. Ne deduco che del flag posso farne a meno.
A meno che tra una modifica ed un'altra deve passare x tempo.
giuseppeD

Quello che tu dici č vero, ma fino in parte.
Quando fai l'update, se non erro, 
ado.net
 o anche ado
ti aggiornano le righe solamente se la coincidenza tra
ultima scrittura lato server e ultima scrittura lato client
coincidono.
Questo significa che se A si collega e prende il recordset,
B idem con patate, poi a fa quello che fa e poi aggiorna
e poi arriva B che deve aggiornare, Ado.net e Ado
(teoricamente) dovrebbe bloccare la scrittura di B perchč
non coerente.
Diversamente, se proprio non lo fa, fallo tu nei tuoi programmi
cosě come faccio io.
Io non adopero i lock lato server, o lato client. Aggiungo
solo 2 campi in piů per ogni tabella. Chi ha scritto l'ultima volta
e chi ha modificato l'ultima volta. In update, se i valori recuperati
sono gli stessi sulla tabella, procedo, diversamente sputo fuori
errore.
Diciamo che potrei perdere il lavoro fatto da B, ma perň non
ho inchiodato una macchina e soprattutto non ho generato inutili
traffici di rete, per interrogazioni esose in termini di memoria.
Ciao Andrea

 errore.
Cosa intendi per : valori recuperati ?
E quale è la diversità che fa scattare il warning e non permette a B di
eseguire l'Update ?
Puoi gentilmente chiarire questi passaggi ?
grazie
giuseppeD

Immaginati
Tabella A
Campo ID = 1
Campo Nome = ciccio
Campo UtenteUltimoAggiornamento = Andrea
Campo DataUltimoAggiornamento = 10/07/2002 10:36:27:586
X fa una select sul campo per recuperare tutti i valori, così che li
vede a video e poi ci lavora.
Y fa la stessa cosa.
Poco dopo X, lancia l'update e la tabella A sarà così
Campo ID = 1
Campo Nome = ciccio
Campo UtenteUltimoAggiornamento = X
Campo DataUltimoAggiornamento = 14/07/2002 17:20:57:826
Quando Y poi tenta l'update anche lui, faccio ciò che non ho detto
sopra per X, ovvero una select per vedere se il record 1 incrociato
con i campi Utente e Data Ultimo Aggiornamento sono gli stessi.
Logico che se una delle tre chiavi è cambiata, il record non esiste
e di conseguenza dico a Y che non può proseguire nell'operazione.
Più chiaro ora?
Ciao Andrea