Newsgroup: it.comp.lang.visual-basic
Titolo: SQL ID

Ciao a tutti! Allora ho un quesito da porvi o meglio... un consiglio da
chiedervi! Lavoro con .net verso SQL. Sto progettando un DB abbastanza
complesso dove molti utenti fanno un continuo accesso. Volevo chiedervi come
da oggetto qual'e' il modo migliore per creare il campo ID delle mie
tabelle. Mi spiego meglio... fino ad oggi ho utilizzato un campo char(12)
composto cosi yymmgghhmmss con i valori della data e dell'ora
dell'inserimento. Questo però nel mio caso può dare origine ad una
duplicazione di chiave che vorrei vivamente evitare di gestire... Volevo
chiedere se c'e' un modo più furbo in SQL per creare questo ID. La cosa
migliore sarebbe quella che l'ID lo creasse direttamente SQL. Ma è possibile
fare questo senza però avere un numero limitato di inserimenti? Se si come?
Altre idee in proposito sono bene accette! Grazie!

 proposito sono bene accette! Grazie!
campo autoincrementante?
-- 
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

Su access il data type era contatore... su SQL qual'è l'equivalente?
Poi un tipo di campo strutturato così non è limitato nel tempo? Una volta
utilizzato l'ID e cancellato il valore non viene
+ sostituito :-(

 ha scritto nel messaggio
news:ca6ta4$553$1...@serv1.iunet.it...

 No!
Ciao, Vincenzo


NO! Cosa?!


La tua domanda era questa:
"Poi un tipo di campo strutturato cosě non č limitato nel tempo?"
La mia risposta era ed č NO
Ciao, Vincenzo

E la risposta a questa domanda?
Su access il data type era contatore... su SQL qual'è l'equivalente?
 Grazie ;-p

 + sostituito :-(
come minimo è un 2^32
non sarà eterno, ma di solito per un po' di tempo regge.



Crei un campo Numeric e imposti:
Identità = SI
Inizio identità = 1
Incremento identità = 1
Ciao, Vincenzo

  Grazie ;-p
Normalmente si usa un INT (un intero lungo) che assume le caratteristiche di
un contatore tramite uno specifico costruttore nello script di creazione
della tabella.
Nell'esempio qui sotto viene creata una tabella con un campo
autoincrementante partente dal valore 0 e con incrementi di 1.
CREATE TABLE dbo.miaTabella (
      campoID           INT IDENTITY (0, 1) NOT NULL
    , campoTesto1    VARCHAR(255)      NULL
    , campoTesto2    VARCHAR(255)      NULL
    , campoTesto3    VARCHAR(255)      NULL
    , CONSTRAINT PK_miaTabella   PRIMARY KEY CLUSTERED (campoID)
    )
GO
Da notare che la cancellazione completa della tabella non resetta il valore
del contatore, ovvero, supponendo che nella tabella siano presenti n righe
con valore di campoID massimo pari a 100 (SELECT MAX(campoID) riporta 100)
al seguito dell'esecuzione dell'istruzione
    DELETE FROM miaTabella
la successiva
    INSERT INTO miaTabella (campoTesto1, campoTesto2, campoTesto3)
VALUES("A", "B", "C")
farà si che venga inserita la riga
    101, A, B, C
Se invece del "DELETE FROM miaTabella" si usasse invece
    TRUNCATE miaTabella
la stessa INSERT porterebbe all'inserimento della riga
    0, A, B, C
Mmmm ... spero di essere stato comprensibile.
Un salutone
Andrea Alberto "Twin Aces" Martinoli
From Italy with a smile! :-)

Doraemon ha scritto:

Un suggerimento,
una tabella contatore,
alla richiesta di un numero, la blocchi,
leggi il numero, lo incrementi di uno,
lo assegni ad una variabile,
update della colonna contatore,
rimuovi il blocco tabella.
Ave
giuseppeD
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

io ho smesso di usare gli Identity.
Poca flessibilità.
Faccio invece come ha detto giuseppeD
eseguo una transazione nella quale faccio incrementare il campo interessato
di uno e nella stessa transazione poi lo leggo.
poi inserisco il nuovo record con il valore appena letto :-)
questo mi permette di pasticciare come voglio sul database di debug, di
copiare dati qua e la senza problemi, di impostare l'indice al punto di
partenza che voglio, poi riportarlo indietro e cancellare gli ultimi
inserimenti con maggiore flessibilità. Imho.
ovvio che:
- nel database di release quel campo non lo tocca nessuno a parte me.
- il database è documentato in ogni sua parte :-)
- prima di far girare una procedura sul database di release la si testa
prima per bene su quello di prova.