Newsgroup: it.comp.software.database
Titolo: Problemi con campi Identity di SQL Server

Sto iniziando a lavorare con SQLSVR (MSDE in realtà): mi stanno dando noie
gli "autonumber".
Se apro un recordset basato su una tabella che contiene un campo Identità:
mi viene restituito un errore ODBC del tipo "Usare DbSeeChanges se la
tabella contiene una colonna Identity".
Anche se aggiungo la costante dbseechanges non cambia nulla!
Ne consegue che non riesco ad aggiungere records in quella dannata tabella
;-(
Altra faccenda: il contatore viene valutato dopo l'aggiornamento del record,
quindi l'unico modo sicuro per rilevarne il valore parrebbe essere il
predicato @@identity del TSQL del Server.
Però all'atto pratico non so ancora come sfruttarlo da VB: sapete darmi una
dritta?
Chiaramente se questi problemi non sono risolubili rinuncerò ad utilizzare
contatori, ma se M$ li ha creati dovrebbero essere utilizzabili, no?
Ciao a tutti.

 ma se M$ li ha creati dovrebbero essere utilizzabili, no?
Se MS ha creato Project dovrebbe servire a qualcosa... o no ?
Davide

 Usa "INSERT INTO..." invece di recordset.add() e vedrai che funziona.
Ehmmm, quindi devo creare una stored procedure e passarle dei parametri
attraverso SQL Pass trought?
Grazie, ciao.
Marco

 attraverso SQL Pass trought?
Una SP e' un'ottima cosa, ma non puoi inviare un semplice comando
INSERT INTO.. al database ?
Davide

 INSERT INTO.. al database ?
Attraverso una connessione Pass trought?
Beh, appena ho tempo ci provo: credevo si dovesse fare una SP.
Un'altra cosa Davide (non l'hai scritta sulle FAQ): qualunque enunciato che
aggiorni dati sul Server (SP o Trigger) lo fa in maniera "trasparente"?
Ovvero io non devo preoccuparmi che gli aggiornamenti vadano a buon fine o
meno (vedi transazioni con VB): ci penserà il Server immagino.
Quindi, io lancio una SP che aggiorna dati in una tabella utilizzata da 100
utenti: teoricamente il Server dovrebbe gestirsi le sue cosette e portare
affidabilmente a buon fine il batch, è così?
Ciao: Marco

 affidabilmente a buon fine il batch, è così?
Questo dipende da come il Server si gestisce la concorrenza. Esistono
sostanzialmente due "scuole" quella Oracle e quella Sybase/Microsoft.
In Oracle il server "blocca" il record poco prima della modifica, ogni
altro utente che sta' leggendo il record, usera' il log delle transazioni
per "ricostruire" il valore precedente finche' la modifica non e'
terminata. In Sybase/MS se un'utente sta' leggendo un record, nessun
altro utente puo' modificarlo. E se un utente sta modificando un record
nessun altro puo' leggerlo finche' la modifica non e' completata.
Davide

 nessun altro puo' leggerlo finche' la modifica non e' completata.
Ok, supponiamo i 100 utenti stiano leggendo/scrivendo sulla tabella in
questione.
Io lancio la SP che aggiorna tutti i records (che so cambia un'aliquota):
che succede?
L'aggiornamento si blocca automaticamente sulle righe lette da altri utenti
per poi sbloccarsi quando i medesimi "mollano l'osso", oppure vengono
generati degli errori da gestire (ma come?).
Ti ringrazio per le preziose informazioni Davide ;-)
Ciao: Marco

 che succede?
Che la SP si ferma ogni volta, finche' non riesce ad acquisire un lock
sulla 'pagina' (gruppo di record) che deve aggiornare, poi procede,
se ci sono molti lock in lettura puo' darsi che la SP non riesca a
fare il lock per timeout, in questo caso ottieni un'errore.
Davide

 fare il lock per timeout, in questo caso ottieni un'errore.
Perfetto, quindi grosso modo funziona come immaginavo.
Ultimo caso (e concludo con sta storia): se un errore di TimeOut dovuto alle
troppe connessioni blocca la SP a metà, la tabella sarà solo parzialmente
aggiornata, giusto?
In tal caso sarebbe stato meglio lavorare con una logica transazionale:
sulla carta il Rollback dovrebbe sempre ripristinare la situazione di
partenza...
Ciao: Marco

 aggiornata, giusto?
Solo se non implementi una transazione, ma se stai usando una SP
do' per scontato che tu stia usando una transazione.
Davide