Newsgroup: it.comp.appl.access
Titolo: Contatori su Jet e MSDE/SQL server

Ho un DB su A2000 e in tutte le tabelle ho un campo contatore, un 
identificativo utente e la chiave primaria che e' composta da utente + 
contatore (es. utente 99, contatore 123, chiave = 99123).
In tutti gli inserimenti da maschera e nelle varie routine ricalcolo il 
campo chiave come sopra descritto.
Il problema e' che ho in mente di passare la base dati su SQL Server, e 
facendo delle prove com MSDE ho visto che questo metodo non puo' 
funzionare perche' il contatore viene riempito solamente al salvataggio 
del record e quindi la routine di generazione della chiave trova sempre 
contatore = null.
Non posso usare funzioni tipo DMax perche' devo eseguire operazioni 
complesse su molti record e rallenterei un bel po' l'applicazione.
Non conosco SQL server e quindi non so se e' possibile farlo con stored 
proc o altro.
C'e' qualcuno che ha gia' avuto a che fare con problemi del genere ?
Grazie mille per qualsiasi suggerimento.
Ciao
-- 
JBad

 C'e' qualcuno che ha gia' avuto a che fare con problemi del genere ?
Hai male impostato la cosa....a che scopo il contatore se poi ti crei la
chiave a mano?
Saluti.
Luciano
(DOC)

 wrote in message
MPG.15469e342...@news.tin.it...

Sì, è vero.
Su SQL Server la valorizzazione del contatore avviene solo quando si salva
il record e non, come con Jet, quando si esce dal campo contatore.
Quindi tutti i porting da un sistema all'altro devono risolvere questa
questione.
Io da codice salvo un record vuoto che assegna in pratica il solo valore del
contatore e poi ci ritorno per updatare gli altri dati.
Adatta tu il tuo esempio tenendo conto della chiave (su cui non entro nei
particolari).
Ciao
:-) Luciana

 says...

Il DB potra' essere utilizzato in sedi distaccate e quindi dovro' 
prevedere delle routine di aggiornamento.
Ho scelto quindi di utilizzare una chiave primaria composta dall'utente 
(o gruppo di utenti che utilizzano lo stesso DB) e dal contatore, in modo 
da avere la sicurezza che in ogni singolo DB avro' chiavi uniche grazie 
al contatore, su DB diversi sara' la parte utente a garantire 
l'univocita' della chiave.
-- 
JBad

l'univocita' della chiave.
Forse sarebbe meglio usufruire delle funzionalità di replica di SQL per questa problematica.
Comunque, perchè costruire a runtime l'ID con l'info utente?
Non è meglio salvare in un altro campo l'ID utente e definire una chiave primaria doppia
Contatore+IDutente?
Ciao, warp

 Ciao, warp
Per quanto riguarda le funzionalita' di replica di SQL non le ho mai 
usate, ma gli aggiornamenti che devo fare devono essere controllati da 
codice e penso che in questo caso la replica non possa essere utilizzata.
Comunque se la conosci qualsiasi consiglio e' prezioso ;)
I motivi per i quali non ho creato una chiave doppia:
-L'utente mi serve per 2 cose distinte: per calcolare la chiave primaria 
quando creo un nuovo record e per memorizzare l'ultimo utente che lo ha 
modificato; se lo mettessi in chiave con il contatore alla modifica di un 
record avrei un aggiornamento a catena di tutte le tabelle collegate.
-La chiave primaria viene utilizzata come codice per gli articoli e i 
vari documenti e avere due campi distinti che la identificano diventa un 
po' complicato da gestire (es: non posso fare una combo box per 
selezionare un'articolo perche' ho 2 campi da collegare e non 1).
Non mi sono venuti in mente altri metodi ma, come ti ho detto sopra, 
accetto tutti i consigli!
Ciao e grazie.
-- 
JBad

accetto tutti i consigli!
Bello rognoso il punto 1) :-/
Mah, a questo punto prova a smacchinare come ti suggerisce Luciana...
Ciao, warp