El principio de funcionamiento del actualizador es el siguiente una vez pulsemos el botón actualizar se van a ir ejecutando los siguientes pasos hasta terminar con la base de datos actualizada:
1. Comprobaciones previas
El objetivo de este paso es mostrarnos la relación de aspectos que crean inconsistencia de datos en la base de datos que vamos a actualizar (BD Cliente). Nuestro objetivo debe ser solucionarlas antes de avanzar con el proceso de actualización. El script que se ejecuta es el procedimiento zActualizador_ComprobacionesPrevias y se encarga de revisar:
§ Posibles registros en zActualizador_Scripts_Clientes
§ Que falten registros clave: cliente 0, serie 0, serie prov 0, artículo 0, artículo portes, ...
§ Todas las FK que fallarán
§ Ofertas, Pedidos, Pedidos de proveedor con moneda distinta de euro cuyo Cambio =0
§ Ofertas, Pedidos, Pedidos de proveedor Descuento > 100
§ Storeds con parámetros distintos
§ Cuentas contables repetidas o a NULL
§ Tipos de cuentas contables con máscara errónea
§ Buscadores rotos
§ Objetos mal nombrados (con espacios)
§ Vinculaciones con otras bases de datos
Todas las posibles inconsistencias de datos que muestre este paso se deben subsanar, para ello se requiere de conocimientos de TransactSQL. En la sección FAQs del actualizador se documentan los ejemplos más comunes que suelen salir en este paso.
2. Generación Scripts Cliente
Guarda todos los objetos (tablas, triggers, claves ajenas…) personalizados del cliente. Una vez pasado este punto si tenemos que cerrar la aplicación o esta se cierra inesperadamente, no podemos volver a empezar el proceso de actualización por el siguiente paso.
Si en este paso aparece error no se puede continuar hasta que se revise y arreglen los datos. La actualización no es correcta.
| En el caso en que se haya tenido que cerrar el actualizador, será necesario restaurar la base de datos del cliente y, aplicando las soluciones generadas en ella, reiniciar la actualización. La razón de esta restauración es que en este paso se han eliminado los códigos personalizados y se han almacenado en una tabla temporal. Tabla de la que se eliminarán al reiniciar el actualizador, no pudiéndose restaurar estos códigos personalizados en el paso 6. Restauración Scripts Cliente. |
En la sección FAQs del actualizador se documentan los ejemplos más comunes que suelen salir en este paso.
3. Ejecución Scripts Previos
Antes de empezar a actualizar, dependiendo la versión se ejecutan unos scripts preestablecidos de fábrica para adaptar la base de datos a la actualización
Si en este paso aparece error no se puede continuar hasta que se revise y arreglen los datos. La actualización no es correcta.
En la sección FAQs del actualizador se documentan los ejemplos más comunes que suelen salir en este paso.
4. Actualización estructura
Este paso es el que más tiempo suele costar de todos.
Copia todos los datos en una base de datos temporal llamada Tmp_Actualizador_xxxxx. Para ello es necesario que exista suficiente espacio en el servidor para duplicar la base de datos.
Elimina todos los objetos de la base de datos original.
Crea nuevos objetos, guiado por la nueva estructura de la BD Vacía de la versión destino.
Mueve los datos de Tmp_Actualizador_xxxxx a la nueva base de datos actualizada.
En este punto es donde el programa puede mostrar errores más críticos. Si ya hemos pasado por esto en alguna actualización de prueba previa ya habremos solucionado los típicos errores de datos incoherentes. Si no, irán apareciendo los errores en el panel de mensajes del Actualizador junto con el script que ha fallado para que podamos solucionar cada asunto.
Las relaciones entre las tablas nuevas no se crean hasta que no se han vuelto a llenar de datos. Esto significa que, los datos antiguos pueden no cumplir la integridad, y si la relación se ha creado con la cláusula WITH NOCHECK, no habrá ningún problema en mantenerlos.
Si la integridad se implementa mediante triggers, entonces no hay ningún problema, ya que los triggers no se activan hasta que las tablas nuevas están cargadas.
Si en este paso aparece un error, el actualizador se detiene. Podremos darle a CONTINUAR si ya hemos arreglado ese problema por medio del Management Studio y pudo ejecutarse con éxito el script asociado al mensaje de error. Si no se arregla ese error y pulsamos CONTINUAR, volverá a detenerse el Actualizador y a aparecer el mismo error continuamente hasta que se resuelva.
En la sección FAQs del actualizador se documentan los ejemplos más comunes que suelen salir en este paso.
5. Ejecución scripts posteriores
Son scripts de bases de datos para actualizar datos o valores nuevos que no se han podido realizar hasta que la estructura estuviese completada.
En la sección FAQs del actualizador se documentan los ejemplos más comunes que suelen salir en este paso.
6. Restauración scripts clientes
Reestablecemos los objetos personalizados que tuviera el cliente. Previamente, el actualizador los había guardado en la tabla zactualizador_scripts_cliente con el campo actualizador a 1 cuando se ejecutó el paso 2.
En este paso también pueden aparecer errores relacionados con anomalías en la definición de esos objetos personalizados. También nos mostrará el script que ha dado el error, así que si el actualizador se para aquí podremos ver de qué script personalizado se trata y tomar la decisión de si lo volvemos a poner en la nueva versión, o no.
Si lo vamos a poner será necesario modificarlo para poder darlo de alta correctamente. Tomaremos el script, lo adaptaremos, y lo crearemos ejecutando el script mediante el Management Studio y dándole permisos mediante un zpermisos.
Una vez adaptado y ejecutado, teniendo en cuenta que tenemos el actualizador detenido, acudiremos al menú Opciones - Mostrar Scripts Personalizados, buscaremos el objeto que generó el error, y desmarcaremos el check EJECUTAR para que el Actualizador no trate de volver a crearlo con la definición antigua.
Después de esto, cerramos la ventana de Scripts Personalizados y pulsamos CONTINUAR para que siga avanzando la actualización.
En la sección FAQs del actualizador se documentan los ejemplos más comunes que suelen salir en este paso.
7. Ejecución scripts finales
Pequeños detalles scripts que no dan cabida a estar en los pasos anteriores y el programador indica que se realicen en este punto.
En la sección FAQs del actualizador se documentan los ejemplos más comunes que suelen salir en este paso.
8. Recompilación
Es el último punto, donde se hacen comprobaciones para que las colecciones muestren todos los campos del objeto hijo y actualización de la versión de la base de datos.
Este proceso si da error lo podemos ejecutar, en modo por pasos, todas las veces que hiciera falta hasta tener los datos arreglados.
Principalmente recompila todos los objetos (zrecompilatodo) para asegurarse que las dependencias son correctas.
Si existe alguna colección que no tuviera todos los campos del objeto y esto si fuera correcta podemos obviarla para que termine el proceso de recompilar indicando que esa colección es un objeto (campo colección de la tabla objetos a 0) una vez termine este punto volvemos a dejar la colección con el valor correcto, 1.
En la sección FAQs del actualizador se documentan los ejemplos más comunes que suelen salir en este paso.
9. FIN
Después de recompilar si el último paso ha sido satisfactorio aparece un mensaje indicando que la base de datos se ha actualizado de forma correcta y si queremos cambiar la versión.
Una vez actualizada la base de datos se recomienda revisar dentro del ERP ya las posibles pantallas personalizadas así como los procesos críticos para el uso del programa.
¿Le ha sido útil este artículo?
¡Qué bien!
Gracias por sus comentarios
¡Sentimos mucho no haber sido de ayuda!
Gracias por sus comentarios
Sus comentarios se han enviado
Agradecemos su esfuerzo e intentaremos corregir el artículo