salve, byrollo_rg@hotmail.com wrote: > Mi capita spesso di definire chiavi primarie di tipo tinyint con > proprietà IDENTITY(1,1), e spesso mi trovo a dover testare il db con > loop di insert e delete fittizi che però portano via via al > raggiungimento del limite massimo di 255. Sol del truncate table, ma > avevo in mente un procedimento differente. > > Vorrei creare una funzione scalare con la quale anziché lavorare sulla > proprietà IDENTITY posso sfruttare la proprietà DEFAULT per generare > valori progressivi univoci > .... e se elimini tutte le righe tranne quella con ID = 255? passi a "riciclare" i gap oppure ti fermi (o vai in errore)? saluti -- Andrea Montanari (Microsoft MVP - SQL Server) http://www.asql.biz http://italy.mvps.org DbaMgr2k ver 0.21.0 - DbaMgr ver 0.65.0 and further SQL Tools --------- remove DMO to reply

byrollo_rg@hotmail.com wrote: > Oltre la strada della funzione sul valore di default mi viene in mente > quella del trigger che ne pensate? Ma io mi chiedo, che senso ha definire una colonna IDENTITY con data type tinyint se prevedi di inserire più di 255 righe?! Ciao! -- Lorenzo Benaglia Microsoft MVP - SQL Server http://blogs.dotnethell.it/lorenzo http://italy.mvps.org

byrollo_rg@hotmail.com wrote: >> e se elimini tutte le righe tranne quella con ID = 255? >> >> passi a "riciclare" i gap oppure ti fermi (o vai in errore)? >> saluti > > Se la colonna ha come IDENTITY(1,1) su un campo [tinyint] una volta > raggiunto il limite 255 andrà sempre in errore ad ogni nuova aggiunta, > anche cancellando tutti i record, a meno che non si effettui un > truncate sulla tabella. > Oltre la strada della funzione sul valore di default > Andrea ti segnalava che se elimini tutte le righe tranna quella con ID= 255 anche la tua soluzione che calcola il valore di default ti indurrà in errore, visto che cercherà di restituire come nuovo valore 256 che non è ammesso per un tinyint. > mi viene in mente quella del trigger che ne pensate? > Che fin tanto che ragioni sul max + 1 avrai lo stesso problema di sopra. Domanda, se hai scelto come tipo di dato il tinyint perché sai che in produzione non avrai mai più di 256 righe, che ti costa farlo diventare un int per farti tutte le prove che vuoi in ambiente di test? Poi lo lasci sempre a int, tanto ripeto che se il numero di righe reali è così ridotto, usare un tinyint piuttosto che un int è una fesseria. Ciao, Alessandro

byrollo_rg@hotmail.com wrote: > Hai qualche consiglio da darmi? In fase di test fai ogni tanto una bella TRUNCATE TABLE per svuotare la tabella resettando il seme della proprietà IDENTITY. > Ciao e grazie a tutti ;) Prego. Ciao! -- Lorenzo Benaglia Microsoft MVP - SQL Server http://blogs.dotnethell.it/lorenzo http://italy.mvps.org

AlessandroD wrote: > Poi lo lasci sempre a int, tanto ripeto che se il numero di righe > reali è così ridotto, usare un tinyint piuttosto che un int è una > fesseria. Questa me la spieghi: :-) - int occupa 4 Bytes; - tinyint occupa 1 Byte. Secondo il tuo ragionamento usiamo sempre bigint, tanto oggi il costo della RAM e degli HD è irrilevante :-D Ciao! -- Lorenzo Benaglia Microsoft MVP - SQL Server http://blogs.dotnethell.it/lorenzo http://italy.mvps.org

Lorenzo Benaglia wrote: > AlessandroD wrote: >> Poi lo lasci sempre a int, tanto ripeto che se il numero di righe >> reali è così ridotto, usare un tinyint piuttosto che un int è una >> fesseria. > > Questa me la spieghi: :-) > - int occupa 4 Bytes; > - tinyint occupa 1 Byte. > > Secondo il tuo ragionamento usiamo sempre bigint, tanto oggi il costo > della RAM e degli HD è irrilevante :-D > No, hai fraintesto. Se in produzione la tabella avrà al massimo 256 righe, sai che risparmio sono 256 * 3=768 bytes... Se in test si deve divertire a caricare e svuotare dati senza star li a resettare ogni tot il campo identity, è sicuramente più comodo adottare il tipo int e lasciarlo tale anche in produzione. Ciao, Alessandro