Newsgroup: it.comp.lang.visual-basic
Titolo: Problemi con il Contatore

Salve a tutti.
Premetto:
-  Uso Vb6, ADO 2.7, Jet 4.0 (Access 2000).
Recordset lato server, di tipo keyset, blocco pessimistico.
- Ho una tabella con un campo contatore (ID autoincrementato) impostato come
chiave primaria
- In rete, (ma anche in locale simulando una multiutenza)
Vi espongo questo quesito:
1) dal PC1 lancio un addNew e il mio contatore si autoincrementa portandosi
ad esempio da 1000 a 1001. Fin qui tutto OK.
2) dal PC2 lancio un addNew e il mio contatore si autoincrementa portandosi
1002. Fin qui tutto OK.
3)  Salvo il record del PC2 con contatore 1002. Fin qui tutto OK.
4)  Salvo il record del PC1 con contatore 1001. Fin qui tutto OK.
5) Controllo il database ed OK
6) SE dal PC1 lancio il comando addNew , vedo che il campo contatore
riporta il valore 1002 e se salvo questo record mi da un errore di
duplicazione chiave primaria, ovviamente.
Ho provato con Requery e Refresh prima dell'AddNew ma riporta sempre il
numero di contatore errato. Come  ottenere l'ID esatto, senza chiudere tutto
l'applicativo ? da chi dipende da Jet o da ADO il conteggio del contatore
fittizzio ?
Idee ? Soluzioni ? Motivazioni ?
Spero di essere stato chiaro.
Grazie anticipatamente

Grazie anticipatamente
nonostante i tuoi sforzi non sei stato chiaro, mi dispiace, 
cmq sei un pivello!
.....................speravi fosse una risposta utile la mia, vero? ^_^
se ti prostrerai ai miei piedi, ti darò la soluzione
Ciao
Silvia.
--
www.silvietta.it
...everyone's invited!
Non Esiste Una Razza Bianca, Benche' Se Ne Parli Tanto: Ogni Uomo Bianco E' Solamente Un Uomo Scolorito 

 cmq sei un pivello!
certo che allo studiomarketing dovete volervi un bene dell'anima...
-- 
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

Lasciate perdere la mia collega burlona ...

 duplicazione chiave primaria, ovviamente.
Se usi un cursore lato client ogni client avrą il suo bel progressivo
parallelo, con le problematiche che hai riscontrato ;)
Ciao
--
Math Parser : 
http://www.neodatatype.net
FlowChart   : 
http://www.neodatatype.net/dump/flowchart/dir.asp
Sito Comune : 
http://www.it-lang-vb.net

 Recordset lato server, di tipo keyset, blocco pessimistico.
[snip]
Vorresti che la concorrenza funzionasse bene con il blocco pessimistico?,
comunque sia il mio consiglio č:
- fai una revisione del tuo progetto in modo tale da non far mai rs.addnew
di quella tabella
- utilizza esclusivamente la "insert into" per generare nuovi ;
Eventualmente a quel punto puoi fare una refresh dei tuoi dati.
Esempio (che ti restituisce l'ultimo contatore utilizzato / inserito)
 Dim cn As ADODB.Connection
 Dim rs As ADODB.Recordset
 Dim nuovo As Long
 Set cn = New ADODB.Connection
 cn.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=mydb.mdb;Persist Security Info=False"
 cn.Open
 cn.Execute "INSERT INTO TabAutonumber (Descrizione) VALUES ('prova')"
 Set rs = New ADODB.Recordset
 Set rs = cn.Execute("SELECT @@IDENTITY AS newId")
'su rs.fields("newid") hai il nuovo numero utilizzato
cn.Close



Io sono d'accordo con te, ma il problema che mi ha costretto ad usare
l'addnew è il fatto di essere costretto a usare la stessa maschera con gli
stessi controlli bindati : dovevo pulire i campi per l'inserimento, caricare
alcuni default, e aspettare che il cliente salvi senza generare alcun
record.
Gli ordini sono quelli di non creare nulla se non al momento del salvataggio
del record.
Io lo trovo inutile ma ... (Al limite creavo e cancellavo all'occorenza,
visto che non ho problemi di progressività dell ' ID, magari stavo attento a
compattare il db + spesso !).
Tutto perchè un cliente deve poter decidere di creare un nuovo record, poi
prendere il caffè, e dopo qualche ora decidere di salvarlo o meno.
Adesso visto il problema, ho pensato di creare un recordset disconnesso da
assegnare vuoto all'applicativo al momento della creazione di un nuovo
record, e successivamente al momento del salvataggio utilizzare una bella
INSERT INTO copiando dal disconnesso al db reale.
Altrimenti dovrei usare dei database temporanei, identici a quello reale, ma
solo per creare record temporanei. (Troppo incasinato !?)
Che fare tra le due? Altre proposte ?
Grazie a tutti, siete molto gentili