Newsgroup: it.comp.lang.visual-basic
Titolo: ADO.NET - Bloccare la lettura di una tabella

Salve a tutti. Sto realizzando una funzione che legge alcuni record da una
tabella (A), esegue dei calcoli e aggiorna un'altra tabella (B).
Visto che il programma, e la funzione in questione, può essere utilizzato da
più persone insieme e contemporaneamente, ho la necessità di bloccare in
lettura la tabella (A) il tempo necessario per eseguire i calcoli e
aggiornare la tabella (B).
Ho provato con le SqlTransaction con pessimi risultati: sono riuscito solo
ad fare eventualemente il Rollback
Sto pensando di utilizzare dei semafori
Esiste qualcosa in SQL: un comando SELECT ... che inibisca la lettura per
una cerchia di record ?
datemi un consiglio ....
Grazie.
P.S. per la funzione che sto realizzando la gestione dei conflitti, in fase
di salvataggio, non va bene

 wrote in message
news:8W%Ia.108224$Ny5.3...@twister2.libero.it...


 necessità neppure di transaction) aggiorni i dati sulla B
Il suggerimento non è male (anche se non sono come dovrei fare).
Il problema però si pone in altri termini:
la tabella (A) di fatto non viene mai modificata, viene solo letta.
Es:
Tabella (A)
IDProd |     Descrizione | Prezzo
1    Latte                2 ?
2    Caffé                5?
3    Pane                10?
Tabella (B)
ID IDProd            Costo     data pagamento
1    1                1                 15/05/2003
2    3                4                 ....
3    2                3                 .....
4    1                1                 .....
l'utente si ritrova un elenco di prodotti da pagare, (da pagare anche
parzialmente). Questo elenco viene generato da una query es:
2    caffé            2
3    Pane            6
Da notare che il latte non c'è più in quanto già pagato totalmente.
la questione è: se due utenti leggono i dati dei prodotti da pagare vedranno
le stesse informazioni, potranno selezionare gli stessi prodotti, ma al
momento di dare ok solo uno di loro due deve riuscire a pagare ciò che ha
selezionato.
grazie per l'aiuto, spero di essere stato chiaro.

 selezionato.
Credo che tu possa risolvere solo con la query di update. Nella where della
update dovrai controllare se il prodotto è già stato pagato interamente, e
in questo caso l'update avrà luogo.
Così facendo, quando il primo utente tenta di pagare il Pane, riuscirà. Il
secondo utente invece si vedrà rispondere picche dal db perchè la where avrà
una condizione false che impedirà l'update.
Visto che le query al db vengono di default gestite in sequenza (il
meccanismo è più complesso ma grossolanamente si può approssimare ad un mero
accodamento), gestendo la giusta clausola where riesci ad evitare meccanismi
di locking o altre cose astruse.
Se il ragionamento dovesse essere più complesso, potrebbe convenire inserire
un 'middle tier' che si mette in mezzo tra i fruitori dei dati e il db. In
questo modo il middle tier saprebbe quale operazione fare e come eseguirla
perchè sarebbe lui stesso l'imbuto verso il db.


 una condizione false che impedirà l'update.
Se mi dici che la soluzione è la query di update (nella quale controllo se
quel prodotto è stato pagato) questo significa che prima devo fare una
insert con valori vuoti (visto che in fase di inserimento non posso
verificare se quel prodotto è stato pagato completamente), poi riempirò i
record creati con la query di update (con i controlli del caso), alla fine
cancello i record vuoti ....
... mi sa che non ho capito verò ?

 in questo caso l'update avrà luogo.
Ci riprovo. Ci ho ripensato, ma tu per query di update intendi un controllo
che risomma tutti gli importi dei pagamenti di un determinato prodotto o è
necessario creare un nuovo campo, nella tabella prodotti, che tenga il conto
di quanto è stato pagato fino a quel momento ?
cioè:
ID| Descrizione | Costo | TotPagato
2 Caffé            15        5
3 Pane             20       11
Questa seconda soluzione è più semplice, ma c'è una ridondanza di dati, in
quanto il totpagato è un doppione della cifra che posso ricavare dalla somma
delle singole "rate" pagate più volte per un prodotto o mi sbaglio
Ciao e grazie

 wrote in message
news:LXaKa.119763$lK4.3...@twister1.libero.it...


 ha scritto nel messaggio
news:eEyXRB1O...@TK2MSFTNGP11.phx.gbl...

Grazie mille, ora ci provo. Ma per gli inserimenti di nuovi record ? La
procedura è uguale? cioè un insert con una select prima ?
ciao e grazie ancora


Ho provato con l'Insert e funziona, anche se per le mie esigenze è un po'
complicato.
Effettivamente però (come ho fatto io) prende un record alla volta
ciao

 Effettivamente però (come ho fatto io) prende un record alla volta
Come hai già sperimentato, anche per l'insert vale la stessa procedura.
Prova a giocare con query un po' più complesse, non te ne pentirai. Vogliamo
farli lavorare questi db o no? ;-)



Effettivamente questo metodo è molto potente.
Ho riscontrato un problema quando deve ricavare un valore (compreso lo zero)
da una somma di record tramite una query incrociata ad Es:
se ho la tabella dei Clienti e quella delle Fatture, e voglio sapere
l'importo totale delle fatture per ogni cliente (anche di chi non ha fatture
che quindi risulterà a zero), ai clienti che non hanno fatture non risulta
zero ma null, se uso il valore ottenuto (null) per altre operazioni salta
tutto.
c'è un modo per convertire null in 0
io ho fatto così ma è un po' scomodo:
IF @Totale is null SELECT @Totale=0
ciao e grazie ancora

 wrote in message
news:URRKa.126035$lK4.3...@twister1.libero.it...


 ha scritto nel messaggio
news:ubUfTCIP...@TK2MSFTNGP10.phx.gbl...
