Cambiare la chiave primaria di una tabella in Business Central: un possibile approccio

Salve lettore, in questo articolo voglio portare alla tua attenzione un problema che in fase di golive su un progetto o in generale su una personalizzazione cliente potrebbe diventare fondamentale poter padroneggiare l’argomento. Mi riferisco a quando il cliente chiede una personalizzazione tale per cui tu debba cambiare la chiave primaria di una tabella che hai già sviluppato per la soluzione.

Sappiamo tutti quanto possa essere devastante dover cambiare la chiave primaria di una tabella che ha già dati. Innanzitutto in fase di pubblicazione, l’app darà errore perché l’aggiunta di un campo sulla chiave primaria rappresenta un punto di rottura per l’app. Considerare l’opzione ForceSync non è la soluzione ottimale perché questo comporta a rilasciare la soluzione e migrare i dati nello stesso momento, con la conseguenza che l’operatività si potrebbe fermare per qualche ora.

Una soluzione che potresti considerare è quella di impostare le proprietà ObsoleteState e ObsoleteReason sulla tabella. In questo modo puoi cominciare a sviluppare la tua soluzione e pensare la migrazione a step pur mantenendo temporaneamente la vecchia soluzione. In questo modo il rilascio può essere fatto a step e hai tutto il tempo per pensare a come migrare i dati, utilizzando, ad esempio, anche tabelle temporanee per il “travaso” dei dati.

La proprietà ObsoleteState può avere questi tre valori:

  • No: è l’impostazione di default. Indica che l’elemento non è obsoleto.
  • Pending: significa che l’elemento diventerà obsoleto in futuro.
  • Removed: l’elemento è stato reso obsoleto.

Hai già utilizzato questa proprietà per aggiornare elementi della tua soluzione? Se vuoi approfondire l’argomento segui questo link per la documentazione ufficiale.

Lascia una risposta