Newsgroup: it.comp.lang.visual-basic
Titolo: Ultimo elemento di una tabella

Scusate il disturbo.
Chi mi sa dire come faccio a ricavare il valore numerico dell'indice
dell'ultimo elemento inserito in una tabella. O, ma forse chiedo troppo, il
primo valore libero!
Grazie in anticipo per la risposta, ma grazie anche per tutti i suggerimenti
e gli aiuti che si trovano su questo newsgroup e sul suo sito comune.

 wrote


Scusate il disturbo.


Credo che compattando il DB, le tabelle provviste di chiave primaria,
vengano ordinate anche fisicamente.
correggetemi se sbaglio.
Ciao e auguri, Giorgio.
pal ha scritto nel messaggio ...


 pal ha scritto


>tieni presente che una tabella e', diciamo cosi', una vista logica di dati



Il problema è quando ho già eliminato qualche record dalla tabella e non si
ha più l'uguaglianza fra record presenti e valore dell'indice dell'ultimo
elemento inserito.
Tieni presente che devo fare tutto con comandi SQL causa esame.

...


 Tieni presente che devo fare tutto con comandi SQL causa esame.
intanto-- a conferma di quello che dicevo sull'ordine fisico delle righe,
cito dalla faq di un sql tutorial molto pratico trovato sulla rete (se credi
posso mandartelo in html o pdf):
Q - Why can't I just ask for the first three rows in a table?
A - Because in relational databases, rows are inserted in no particular
order, that is, the system inserts them in an arbitrary order; so, you can
only request rows using valid SQL features, like ORDER BY, etc.
allora, suppongo che l'indice, cioe' in sostanza un contatore, te lo
aggiorni da solo, seno' (se ci pensa il dbms) il problema non si pone, e
anzi se uno cerca di assegnare lui un valore al contatore i dbms tendono a
prendersela  :)
se la tabella e' strutturata tipo
 counter | firstname | lastname ...
dovresti poter aggiungere una riga con:
 insert into tabella values nuovo_val, paolo, rossi, ... ;
tieni presente che ogni programmatore usa una sua logica nella gestione di
contatori e simili. a qualcuno i salti nella numerazione danno fastidio, a
me no. cmq, se elimini schede, il contatore rivelera' dei buchi, ma mi
_auguro_ che tu non voglia andare a recuperare i numeri che si sono
liberati. suppongo che inserendo dovrai semplicemente incrementare il
contatore.
     rec. 1 --> cont = 1
     ...
     rec. n --> cont = n 'rcount = n
se elimini un rec.
 rcount = n-1
se aggiungi una nuova scheda:
 rec. n+1 --> cont = n+1 'ma rcount = di nuovo n
all'atto pratico ricorrendo al recordcount (se e' questo che intendi con
"indice dell'elemento"), rischi di reinserire un valore che dovrebbe essere
unique nella colonna.
quindi a occhio dovresti prendere il valore di counter nell'ultima linea e
limitarti a incrementare quello. la discordanza fra valore del contatore e
numero delle righe e' esattamente qlo che succede in un dbms tipo access
quando si eliminano delle righe.
in codice molto pseudo,
io proverei a mettere in una var il contatore
 pippo = select max(counter) from tabella;
e a inserire la nuova scheda incrementando la var
 insert into tabella values pippo+1, paolo, rossi, ... ;
ma temo di non poterti aiutare sulla sintassi corretta.
magari senti qualche sequellista vero...
scusami se non ho capito in tappo, ciao, pal

scusami se non ho capito in tappo, ciao, pal
Ma che dici ! Mi hai salvato.
Di nuovo grazie e arrivederci a presto.
E tanti auguri.

 wrote in message
83iabi$ko5$1...@lacerta.tiscalinet.it...



wrote:


Intervengo per problema punto 2)
Se stiamo parlando di db sql puoi farti assegnare l'ID, inserire un record
vuoto e poi usare update.
Anche in questo modo hai comunque il rischio che nel tempo che ci impieghi
qualcun altro faccia la stessa cosa.
Per sql puoi risolvere eseguendo quanto sopra in un'unica "botta" con begin
tran....commit tran.
Esempio:
"BEGIN TRAN qry1; set nocount on; declare @nummax int; SELECT
@nummax=max(pluto) FROM pippo; SELECT @nummax=@nummax+1; insert into pippo
(pluto) values (@nummax); set nocount off; COMMIT TRAN qry1"
Poi lavori normalmente e fai update del record che contiene pluto=@nummax
(che devi esserti salvato ovviamente in una variabile).

Perfettamente d'accordo.
Io infatti uso normalmente le transazioni e un trigger che, all'atto
sel salvataggio, assegna al campo un ID casuale; casuale peraltro fino
a un certo punto, in quanto prima di essere assegnato al campo ne
viene testata l'esistenza.
Se invece ho a che fare con un database Access, faccio la stessa
identica cosa MA con una procedura da VB (verifico con 'COUNT' se l'ID
casuale non e' gia' utilizzato).
Peraltro devo dire che, in base ai miei studi, se si ha a che fare con
indici univoci il problema sta nel fatto che si puo' minimizzare ma
non eliminare del tutto la probabilita' di incappare in un'ID gia'
utilizzato.... Pensa che il problema l'ho dovuto studiare a causa del
fatto che spesso la stored procedure creata a partire da un campo
contatore di Access utilizzando il Microsoft Upsizing Tool spesso e
volentieri mi dava problemi di duplicazione degli indici!!!!
Ciao!
Luca Menegotto.


 > inserito.


 wrote


 wrote in message
dD7a4.6873$1W4....@news.infostrada.it...
