El truco que vamos a comentar es una chorradilla pero nos puede sacar
de algún que otro aprieto
Para explicar mejor lo que se pretende ... vamos a imaginar un caso
hipotético :
· Disponemos de un Axapta para desarrollo
· Disponemos de un Axapta productivo
Como es lógico, el Axapta de desarrollo es el que usamos para
programar y testear los módulos que queramos antes de pasarlos al
Axapta que está usando la empresa en su día a día con sus datos, sus
procesos funcionando a la perfección etc ... (Osea el Axapta
productivo)
Bien, a la hora de actualizar el entorno productivo con las nuevas
modificaciones que hayamos realizado, el nuevo módulo que hemos
desarrollado o el parche que hemos acabado ... lo más recomendable es :
· Buscar un buen momento.
· Parar el entorno productivo.
· Copiar la aplicación de la carpeta desarrollo a la real.
· Entrar y sincronizar
Esto sería lo ideal, pero ... cuantas veces hemos tenido que pasar un
proyecto (xpo) exportando de desarrollo e importando en la productiva o
cuantas veces hemos tenido que "tocar" alguna cosilla en la "buena" y
luego pasarla a desarrollo por las prisas del "corre corre que esto
peta" ... somos humanos y estas cosas pasan
Aquí está el problema
Existen unos códigos de identificación para las tablas y los campos
(tambien para las clases y otras malas hierbas, pero ahora no
importan ), [vease tableid y fieldId].
Estos códigos los genera Axapta automáticamente cada vez que creamos
una tabla o un campo. Como es lógico cada aplicación Axapta genera
sus códigos de manera independiente a cualquier otra aplicación, de
forma que se pueden dar conflictos de identificadores.
Vamos a poner un ejemplo de un posible conflicto de Identificadores :
· Imaginemos que la última tabla que hemos creado en desarrollo tiene el
identificador 39999 y se da la casualidad de que la aplicación productiva
está totalmente actualizada y como es una copia idéntica tenemos la
misma situación de identificadores (la última tambien es 39999).
· Ahora creamos 2 tablas en Desarrollo, la Tabla_A (40000) y la Tabla_B
(40001).
· Resulta que por las prisas del directo ... debemos pasar la
Tabla_B de forma rápida a la aplicación productiva.
· Ni cortos ni perezosos exportamos Tabla_B a un xpo y la importamos en
la aplicación productiva sin acordarnos de marcar un pequeño "check" del
dialogo de importación/exportación.
Esto provoca que al importar la tabla en la aplicación productiva, le
genere un nuevo identificador (40000).
Axapta guarda en una tabla llamada SQLDictionary la "relación" entre un
identificador de tabla o de campo y el nombre de tabla o campo real
dentro del servidor SQL. Digamos que esta tabla le indica a Axapta que
tablas y campos de la base de datos real del SQL se corresponden con
los identificadores de que dispone en el AOT de las capas
sys/var/cus/usr ... etc
Hasta aquí no ha pasado nada malo.
El problema vendrá cuando nos decidamos a realizar una actualización
completa desde la aplicación de desarrollo a la aplicación productiva.
En ese momento es cuando el identificador de nuestra Tabla_B habrá
cambiado en el AOT (recordemos que en la aplicación de desarrollo tenía
el ID 40001 y en cambio en productivo tenía el 40000) pero este cambio
no estará reflejado en la base de datos (SQLDictionary).
Si se nos ocurre la insensatez de sincronizar las tablas del AOT ... pueden
pasar varias cosas y ninguna buena (estamos hablando incluso
de perdida de datos, en según que casos Axapta puede llegar a borrar la
tabla "desvinculada" y volverla a crear vacía con el nuevo ID, y lo mismo
puede ocurrir con campos sueltos de una tabla)
Que podemos hacer ?, pues lo que podemos hacer es regenerar la tabla
SQLDictionary actualizando los identificadores de que disponemos en el
AOT.
Para eso hemos creado este JOB :
x++:
// TrucosAxapta.com // Regenera la tabla que vincula las tablas del AOT con la BBDD staticvoid RegenerarSqlDictionary(Args _args) {
SqlDataDictionary SqlDD;
Dictionary Dict;
TableId TabId;
SysOperationProgress Progreso;
dictTable dTable;
SqlDictionary SqlDictionary;
;
#AviFiles
Progreso = new SysOperationProgress();
Progreso.setCaption("Reconstruyendo SQLDictionary");
Progreso.setAnimation(#AviUpdate);
Dict = new Dictionary();
SqlDD = new SQLDataDictionary();
Ejecutando este job nada más entrar en la aplicación que hemos
actualizado nos da la tranquilidad necesaria para poder sincronizar las
tablas sin tener que sufrir graves consecuencias.
De todas formas despues del job es recomendable ejecutar el proceso "
Comprobar/sincronizar" que encontramos en menú "
Administración/Periódico/Administración SQL"
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Axapta y Dynamics Ax son marcas registradas de Microsoft corporation. Todos los logos y marcas son propiedad de sus respectivos propietarios. Excepto trucosAx.com que este si que es mio :-). (c) 2005 by Manel Querol (Mkz) TrucosAx.com no pertenece ni está asociada a Microsoft corporation. Los fragmentos de código y proyectos importables que aquí se muestren están realizados sobre bancos de pruebas. No nos hacemos responsables de cualquier daño o pérdida de datos que se pudiera originar del hecho de instalar alguno de estos ejemplos en un sistema productivo. Es responsabilidad del usuario ser consciente del impacto que puede ocasionar en sus aplicaciones el uso del código que de aquí extraiga.
Inicio(Noticias) :
Miembros :
Comunidad :
Estadísticas :
Otros Servicios :
Miscelanea :
Enlázanos :
![[axapta-links.com] - The startpage for Axapta](http://3.bp.blogspot.com/_KJlMZfVmojw/SLkHtjWZT9I/AAAAAAAAAxA/jXDYuyUSEQU/S220/Arijit+Basu.JPG)
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
etc ... (Osea el Axapta
... debemos pasar la
