+ Rispondi al Thread
Visualizzazione dei risultati da 1 a 9 su 9

Discussione: Aggiornamento Chiave Primaria

  1. #1
    Maverick03 non è in linea Scolaretto
    Post
    65

    Aggiornamento Chiave Primaria

    Ciao a tutti,
    vorrei chiedere un aiuto per risolvere un problema sulla chiave primaria di una mia tabella, spiego:
    Il database che utilizzo è di tipo mdf e la tabella si chiama SCADENZE. La chiave primaria è un intero autoincrementante.
    Ovviamente La CP numera i record secondo l'ordine 1-2-3-4....... ecc.
    Il problema sta nel fatto che dopo una cancellazione eseguita con il codice:
    codice:
     Private Sub ELIMINA_Click(sender As Object, e As EventArgs) Handles ELIMINA.Click
            Dim chiave As Integer = IDTextBox.Text
            Me.SCADENZETableAdapter.CANCSCAD(chiave)
            Me.SCADENZETableAdapter.Fill(Me.NewProvaDataSet.SCADENZE)
           
            For k As Integer = 0 To DGV3.Rows.Count - 2 'Ciclo per rinumerare la Chiave Primaria
                DGV3(0, k).Value = k + 1
            Next
    
            Me.Validate()
            Me.SCADENZEBindingSource.EndEdit()
            Me.TableAdapterManager.UpdateAll(Me.NewProvaDataSet)
        End Sub
    apparentemente la numerazione della CP è corretta e ai successivi caricamenti della tabella SCADENZE l'ordinamento è 1-2-3-4.....ecc, ma quando inserisco un nuovo record, questo prende la posizione di quello eliminato precedentemente anziché mettersi in coda a tutti gli altri, pur prendendo la corretta numerazione.
    Vorrei semplicemente fare in modo che anche con l'inserimento di un nuovo record si mantenesse l'ordinamento crescente.
    Probabilmente le mie modifiche sono solo a livello di DataSet e non di DataBase e quindi con un ORDER BY ID ottengo il risultato voluto, ma la domanda è: si può modificare la chiave primaria direttamente nel DataBase?

  2. #2
    L'avatar di gibra
    gibra ora è in linea Amanuense
    Luogo
    Breganze (VI)
    Post
    5,989
    Il comportamento corretto 'standard' è proprio quello da te auspicato, ovvero quando si elimina un record il numero della PK va perso, quindi resterà il 'buco' (se così vogliamo chiamarlo) e successivamente, ad ogni nuovo record inserito il numero si incrementa automaticamente.

    Detto questo, e per tale motivo, una PK autoincrementale impostata correttamente non può essere modificata in alcun modo.
    Se la tua tabella lo permette, allora significa che c'è un errore nella definizione del campo.

    Sei sicuro di aver impostato la proprietà Identity su Sì?

    Se correttamente definito il campo, l'unico modo per modificare direttamente la PK è utilizzando l'apposita istruzione
    SET IDENTITY_INSERT (Transact-SQL)
    https://msdn.microsoft.com/it-it/lib...=sql.120).aspx

  3. #3
    Maverick03 non è in linea Scolaretto
    Post
    65
    Ed infatti anche la mia tabella non permette nessuna modifica della PK, come deve essere, la proprietà Identity è impostata su Si.
    Ti ringrazio per avermi confermato che non posso fare modifiche sul DataBase e quindi ho risolto facendo vedere a video una tabella ordinata e lasciando in pace il DataBase che continua a fare il proprio mestiere.

  4. #4
    Luogo
    Padova
    Post
    4,379
    Blogs
    36
    Con la pk impostata come identity il comportamento normale dovrebbe essere la creazione di buchi nella progressione numerica in caso di cancellazione.
    Nella mia carriera ho incontrato però un database (non mi ricordo quale) che si comportava in modo diverso, se ad essere cancellato era l'ultimo numero della serie di identity allora questo veniva recuperato e non perso.
    ----------------------------------------------------------
    Se avete delle domande fatele prima al forum
    Il mio blog su Masterdrive.it
    Il mio blog su Visual-Basic.it

  5. #5
    Sgrubak non è in linea Scolaretto
    Luogo
    Torrazza Piemonte
    Post
    188
    Quote Originariamente inviato da Maverick03 Visualizza il messaggio
    ...Vorrei semplicemente fare in modo che anche con l'inserimento di un nuovo record si mantenesse l'ordinamento crescente...
    Prova impostando la proprietà Sort del BindingSource utilizzando in nome della colonna PK.

  6. #6
    Dev-01 non è in linea Scolaretto
    Post
    403
    Quote Originariamente inviato da Sgrubak Visualizza il messaggio
    Prova impostando la proprietà Sort del BindingSource utilizzando in nome della colonna PK.
    La creazione di un nuovo valore per una chiave primaria numerica intera è per sua natura già ordinata in modo crescente per cui è assolutamente inutile eseguire un sort su una colonna contenente tale tipo di dato.

    I salti di chiave sono assolutamente innocui se il database è ben progettato sopratutto in relazione ad eventuali tabelle correlate.

    In caso contrario affidare un valore sequenziale (ove e qualora eventualmente permesso) in presenza di "vuoti"* potrebbe portare al recupero di dati incoerenti.

    * = in realtà solo noi lo percepiamo tale quando causato da un salto di chiave anche se questa considerazione non ha ragione d'essere né dal punto di vista logico né da quello informatico.

  7. #7
    L'avatar di sspintux
    sspintux non è in linea Very Important Person Ultimo blog: Mappa Italia senza le Google API
    Luogo
    Lazio
    Post
    1,576
    Blogs
    20
    Quote Originariamente inviato da Dev-01 Visualizza il messaggio
    La creazione di un nuovo valore per una chiave primaria numerica intera è per sua natura già ordinata in modo crescente per cui è assolutamente inutile eseguire un sort su una colonna contenente tale tipo di dato.
    ...
    Ciao,

    che mi risulti molti dbms per ottimizzare le prestazioni usano cache in memoria per i dati
    ... e se sono presenti in cache (non modificati) non vanno a rileggerli ogni volta dal disco.

    Immagina che utente1 esegua una interrogazione su una tabella anagrafica con
    i campi IdAnagrafica (PK) , cognome e nome del tipo :
    select * from anagrafica order by cognome ed il dbms metta i dati in cache.

    In seguito Utente2 esegue select * from anagrafica

    IMHO, non avendo specificato alcun tipo di ordinamento per la seconda query ,il DBMS
    si sentirà libero di restituirti i dati ordinati per cognome
    ... anche se il programma li vorrebbe ordinati per la PK.

    In conclusione,
    è sempre necessario specificare l'ordinamento quando è essenziale per i nostri scopi
    Ultima modifica di sspintux; 22-04-2018 01:28 
    Ciao sspintux
    ------------------------------------------------------------

    O Santo Protettore dell'informatico quadratico medio, se puoi allontana da me questo cetriolo amaro!
    Azz! ... questo è un grande porck-around; potremmo addirittura farlo passare per una funzionalità avanzata

  8. #8
    Luogo
    Padova
    Post
    4,379
    Blogs
    36
    l'inserimento di un nuovo elemento quando c'è di mezzo il binding per l'ordine dipende dalla chiave della datatable e non dalla table del database.
    la chiave primaria della table viene attivata e validata solamente con l'update del dataset (insert) quanto è nel dataset fino a quel momento è da considerare "dato scratch" con ciascun record qualificato come modified, deleted o insert
    ----------------------------------------------------------
    Se avete delle domande fatele prima al forum
    Il mio blog su Masterdrive.it
    Il mio blog su Visual-Basic.it

  9. #9
    Dev-01 non è in linea Scolaretto
    Post
    403
    @ sspintux

    Il datacaching è un'opzione disabilitabile e non strettamente necessaria e non un comportamento standard dell'engine core nè durante la scrittura né durante la lettura dei dati.

    Sull'utilità e l'utilizzo non mi esprimo: sarebbe come discutere sul lavorare connessi o meno e la risposta è sempre la stessa: "dipende da quello che devi fare".

    Il mio intervento era relativo al quesito iniziale e quindi legato ai salti di chiave: non aveva nulla a che fare né con le cache né con le query per quanto, nel secondo caso, imprescindibili dalla fruizione dei dati e serviva come base al resto del post del quale è parte integrante e di cui per comodità di lettura riporto uno stralcio:

    I salti di chiave sono assolutamente innocui se il database è ben progettato sopratutto in relazione ad eventuali tabelle correlate.

    In caso contrario affidare un valore sequenziale (ove e qualora eventualmente permesso) in presenza di "vuoti"* potrebbe portare al recupero di dati incoerenti.
    Tale dichiarazione, correttamente contestualizzata, risulta perfettamente in linea con la realtà al netto di utilizzi reali o presunti sia dei dati in tabella quanto dei vari DBMS.

    Nello specifico la "contestazione" o meglio "precisazione" sollevata non tiene conto del contesto della richiesta né della risposta nella sua interezza: i salti di chiave non influiscono sull'ordinamento e sulla qualità/coerenza dei dati strettamente recuperati dalla tabella in nessun caso.
    Ultima modifica di Dev-01; 23-04-2018 14:42 

+ Rispondi al Thread

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi