giovedì 10 dicembre 2015

AX 2012 - R2 CU7 - Errore 'Incorrect syntax' su cancellazione schema

La procedura consigliata per i rilasci in produzione delle modifiche su AX 2012 prevede l'utilizzo di comandi che lavorano sul Model DataBase di AX. In particolare, al fine di limitare la durata del fermo in produzione, è prevista la creazione e l'importazione del modelstore su di uno schema temporaneo e poi l'inversione di questo schema con il 'dbo' una volta fermate le attività.

Con clienti che utilizzano la versione R2 CU7, a volte ho notato che nel fare questa operazione non riuscivo ad applicare il cambio di schema e non mi era più possibile eliminare lo schema temporaneo, nemmeno utilizzando un DROP da SQL. Approfondendo la cosa, mi sono accorto che ciò avveniva quando utilizzavo dei numeri all'inizio del nome dello schema (e.g. 20150101_TemporarySchema).

L'errore che ottenevo era il seguente (riporto solo la parte principale):

 Incorrect syntax near '20150101'.

Provando ad utilizzare apici (',"), parentesi ('[', '(' ) o altri caratteri speciali non riuscivo a risolvere il problema. Approfondendo allora il funzionamento dei comandi Management Shell e di AxUtil per la cancellazione dello schema ho visto che tutti richiamavano la stessa store procedure: XU_DropSchema .

All'interno di questa store procedure, nella parte finale viene richiamato il comando sql per il drop dello schema,

  1. SELECT @DropStatement = 'DROP SCHEMA ' + @schemaName

scritto così però non tiene in considerazione l'eventualità che vi siano numeri nella parte iniziale del nome e SQL Server non riesce ad interpretare correttamente il comando. Ho risolto il problema correggendo questa riga, aggiungendo le parentesi '[' per isolare il nome dello schema.

  1. SELECT @DropStatement = 'DROP SCHEMA [' + @schemaName + ']'

Posso confermare, per esperienza diretta, che la correzione risolve il problema. Inoltre aprendo la stessa store procedure in ambienti R3, ho visto che è stata riscritta e che non presenta più l'errore sulla parte finale. Non ho ancora verificato se il problema sussiste in kernel R2 CU8\CU9.