Hilo iniciado por Iratxe Lejarreta el 1 de agosto de 2016
-
Entradas
-
Hola,
En Microsoft Dynamics AX 2012 R3, no puedo sincronizar y tengo problemas a la hora de ejecutar algunas acciones, porque el sistema me devuelve un error de base de datos.
El problema está que una vista (DimensionAttributeValueSetItemView) en la AOT, la visualizo bajo el desplegable de Tablas, en lugar de Vistas. No sé cómo ha podido desplazarse de lugar, pero ahora el error que tengo es que la aplicación dice que no es una tabla, pero no sé cómo hacer para que vuelva a ser una vista. En la BBDD SqlServer he comproblado que esa vista está correctamente creado como vista y en la tabla SQLDICTIONARY el registro de esta vista está correcto.
¿Cómo puedo solucionar este problema? ¿Cómo puedo convertir una tabla en vista?
Gracias por adelantado.
Hola Iratxe,
Este problema es bastante común en AX 2012, sobre todo al migrar a R3 o instalar un parche, y puede ser causado por dos motivos, por lo que no se puede dar una solución genérica. La mayoría de estos procedimientos están explicados en algunos blogs o páginas de la comunidad oficial, pero en resumen:
El primer motivo es que haya un conflicto de IDs en SQLDICTIONARY o que se haya cambiado la propiedad que indica si es una tabla o una vista (creo recordar de memoria que es FLAGS o algo parecido). Puede que el mismo ID este siendo utilizado para dos objetos, o que se haya producido cualquier tipo de conflicto por el motivo que sea, en este post explico como detectarlo:
http://www.jaestevan.com/problemas-de-sincronizacion-en-microsoft-dynamics-ax-2012/
Si es un entorno de pruebas, simplemente se pueden borrar todos los registros referentes a esta vista de SQLDICTIONARY y también referentes al ID de la vista (esto es, hacer un delete por nombre y otro por ID), que pueden afectar a otros objetos si se estubiera produciendo un conflicto. Al sincronizar la bbdd, estos registros se crearán correctamente y también se re-creará la vista/tabla. PERO HAY UN RIESGO MUY ALTO DE PERDER DATOS, POR LO QUE NO HAY QUE HACERLO NUNCA EN PRODUCCIÓN Y SI SE QUIERE CONSERVAR LOS DATOS HAY QUE SALVAR LA TABLA EN ALGÚN SITIO ANTES DE HACER NADA.
Al ser una vista, algo que sería más sencillo de probar y también más seguro es ir al SQL y borrar la vista. Debería crearse tras la sincronización aunque si en el AOT la detecta como tabla igual no se crea, y hay que recurrir al punto anterior.
El segundo motivo (más probable después de una migración o de instalar un parche) puede ser una incoherencia en los metadatos del AOT, y no de la base de datos. Habría que actuar buscando incoherencias con cuidado igual que en el punto anterior, pero en las tablas ModelElement y ModelElementData. Puede ser útil comparar estos metadatos (hay algunos campos con valores numéricos que es dificil analizar a simple vista) con un entorno que esté funcionando y sincronizando correctamente, y asegurarse que los metadatos son iguales. O símplemente copiarlos de una base de datos a otra, y después compilar y sincronizar.
Espero que alguna te ayude, saludos.
J.A.
Estos procedimientos son peligrosos. No hay que tocar los metadatos nunca en entornos de producción. Aunque el entorno no esté funcionando correctamente, hay un riesgo muy elevado (casi una certeza) de pérdida de datos.
Contestado también (en inglés), aquí:
https://community.dynamics.com/ax/f/33/p/207511/542722
Incluyendo algunos links extra también en inglés.
Hola,
El problema solo está en el entorno de producción, en el entorno de test está correcto. No creo que sea un problema de base de datos porque en la tabla SQLDICTIONARY el registro está correcto: ejecutando select FLAGS from SQLDICTIONARY where name=’DimensionAttributeValueSetItemview’ and fieldid=0; devuelve un 0. No sé cómo continuar porque no tengo las tablas ModelElement y ModelElementData.
Gracias.
Perdón, ejecutando select FLAGS from SQLDICTIONARY where name=’DimensionAttributeValueSetItemview’ and fieldid=0; devuelve un 1
- Debes estar registrado para responder a este debate.