Caso práctico: Actualización desde 4.4.1700 a 4.4.2200 HF3

Introducción 

En este artículo pretendemos mostrarte un caso real de actualización de una base de datos de cliente desde una versión relativamente antigua a una versión más reciente.  El objetivo es aportarte más información en forma de casos reales, que se pueden dar en cualquier actualización desde versiones antiguas o más recientes, y que puedas ver cómo se ha resuelto a nivel técnico cada asunto que ha aparecido.

Si estás leyendo esto, seguro que eres un técnico o tienes cierta solvencia en el manejo de SQL.

En este caso partimos de una base de datos de cliente del sector de los alquiladores de maquinaria en versión 4.4.1700, con un tamaño de base de datos poco mayor de 1 Gb.

Primeros Pasos

Como primer paso y muy importante, hemos hecho una copia de seguridad de la base de datos del cliente para poder restablecerla si la actualización no se pudiese finalizar correctamente.

Después de esto, restauramos o preparamos en la misma instancia SQL una base de datos vacía de la versión destino, en este caso 4.4.2200 HF3. Si no dispones de una base de datos vacía, desde la versión 4.4.2100 el modo de obtenerla es generar una base de datos ejecutando AHORA INSTALL. Consulta aquí las opciones que ofrece Ahora Install.

NOTA: si la intercalación de la instancia así como la de la base de datos del cliente no se corresponde con la habitual SQL_Latin1_General_CP1_CI_AS se debe seguir el proceso de construcción de una vacía que se indica en este artículo.

El siguiente paso será abrir la aplicación Actualizador indicando los datos de conexión oportunos: instancia SQL, base de datos del cliente y base de datos vacía. Como ya te he comentado, ambas estarán ubicadas en la misma instancia indicada.

Una vez dentro del entorno del Actualizador de AHORA ERP, procedemos a lanzar el proceso de actualización en modalidad AUTOMATICO pulsando en el botón ACTUALIZAR.

El proceso de actualización comenzará e irá avanzando por los diferentes PASOS, devolviéndonos la información que proceda según el caso.

En este caso, el proceso de actualización se ha detenido en el primer paso de Comprobaciones Previas.

Como podemos ver en la imagen anterior, el paso de Comprobaciones Previas ha devuelto tres errores críticos, 2 advertencias, y un mensaje informativo.

Los mensajes de error críticos han detenido el proceso de actualización. Por el momento mantendremos el Actualizador abierto tal y como se ha quedado para no perder el hilo de los diferentes aspectos a revisar.

Empezaremos analizando los errores críticos para ir solucionándolos.

Corrección de errores críticos

ERROR 1: FKs erróneas

Tomando el script que nos proporciona el Actualizador podemos consultar en la base de datos del cliente los registros afectados.

Aparecen 409 registros en los que habrá que solucionar este problema de líneas de pedido de venta que tienen relacionadas ofertas que ya no existen. Para ello podemos acudir al artículo FAQs del Actualizador https://ahora.freshdesk.com/support/solutions/articles/44001762524-faqs dado que la solución para este caso está documentada ahí, en el ejemplo 1 de la sección Mensajes en el paso de Comprobaciones previas.

Tomamos el script de solución que ahí se detalla y aplicando los debidos cambios en el nombre de la base de datos (en este caso sustituimos AHORA_4_1_700 por BDCLIENTE441700) lo podremos aplicar directamente sobre la base de datos que estamos actualizando.

UPDATE T1

set IdOferta= NULL, Revision= NULL, IdOfertaLinea= NULL

FROM BDCLIENTE441700..Pedidos_Cli_Lineas T1 WITH (NOLOCK) 

WHERE T1.IdOferta IS NOT NULL AND T1.Revision IS NOT NULL AND T1.IdOfertaLinea IS NOT NULL

AND NOT EXISTS(SELECT 1 FROM BDCLIENTE441700..Ofertas_Cli_Lineas T2

                     WHERE T1.Revision=T2.Revision AND T1.IdOfertaLinea=T2.IdLinea AND T1.IdOferta=T2.IdOferta)

ERROR 2: La definición del patrón de cliente y de los dígitos de subcuenta no son coherentes

Comprobamos el valor del parámetro PATRONCLIENTES en la base de datos del cliente, así como el número de dígitos de los ejercicios contables.

Como podemos ver, los ejercicios contables están configurados a 8 dígitos, y en cambio el parámetro está configurado con 4 + 5 = 9 dígitos.

La recomendación en este caso es solucionarlo forzando a que las subcuentas coincidan en su longitud con la codificación de clientes, es decir, a 9 dígitos. Para ello podemos ejecutar la stored procedure ZActualizaSubcuentas9Digitos sobre la base de datos del cliente y cuando ésta termine modificar los Digitos_Subcuenta de los ejercicios por base de datos. Es decir,

Exec ZActualizaSubcuentas9Digitos

y

update Conta_Ejercicios set Digitos_Subcuenta = 9

 y este asunto quedará solucionado.

ERROR 3. La definición del patrón de proveedor y de los dígitos de subcuenta no son coherentes

Según la comprobación del parámetro PATRONPROVEEDORES, vemos que efectivamente la cadena de texto correspondiente al patrón tiene 6 dígitos, donde el primero de ellos es una coma que habría que eliminar.

Para ello modificaremos el valor del parámetro mediante un update:

update Ceesi_configuracion set Valor = '00000' where Parametro = 'PATRONPROVEEDORES'

En lo referido a los dígitos de subcuenta,  habrá quedado solucionado tras resolver el error 2 que era similar para clientes.

Llegado este punto atenderemos los mensajes de tipo warning.

Revisión de Warnings

En relación a los dos mensajes que hacen referencia a aspectos similares de longitud de subcuentas vs longitud del patrón de clientes o de proveedores, como alguna de las soluciones anteriores ha implicado modificar la longitud de las subcuentas de los ejercicios, los dos mensajes de advertencia pueden haber variado. Así que pulsaremos el botón CONTINUAR de la parte inferior derecha del Actualizador lo que iniciará de nuevo el paso de COMPROBACIONES PREVIAS y si encuentra alguna anomalía nos la presentará nuevamente.

Como podemos ver en la imagen siguiente, esta vez sólo aparecen 3 mensajes del paso de Comprobaciones Previas: 2 warnings relacionados nuevamente con la longitud de cuentas y patrones, y un mensaje informativo que nos da una recomendación para la base de datos.

A pesar de todo ello, el proceso de actualización ya no se detiene por los warnings continuando automáticamente paso a paso hasta llegar al paso final de Recompilación.

En este último paso también nos aparecen mensajes no críticos que deberemos analizar detenidamente.

Acciones Finales
Como parte final del proceso de actualización, aprovechamos para resolver todos los Warnings que podamos.

Este script nos indica qué máscaras no están correctas en el caso de los clientes:

Podemos aprovechar el script para preparar una sentencia de Update que corrija este asunto:

;WITH TiposCuenta_MAL AS ( 

SELECT IdTipoCuentaOperacion,IdTipoCuenta,IdTipoOperacion,Mascara, DescripMascara,9 Digitos_Subcuentas, 5 Digitos_Cliente

FROM [BDCLIENTE441700]..Cuentas_TiposCuentaOperacion

WHERE Mascara LIKE '%{IdCliente}%' AND (LEN(REPLACE(Mascara,'{IdCliente}','')) + 5)<>9)

UPDATE c SET c.Mascara = left(c.Mascara,3) + '0{IdCliente}'

FROM Cuentas_TiposCuentaOperacion c

INNER JOIN TiposCuenta_MAL t ON c.IdTipoCuentaOperacion = t.IdTipoCuentaOperacion AND c.IdTipoCuenta = t.IdTipoCuenta

AND c.IdTipoOperacion = t.IdTipoOperacion  

Continuamos con el siguiente caso.

Este script nos indica qué máscaras no están correctas en el caso de los proveedores,

Ejecutando este script solucionamos este asunto:

;WITH TiposCuentaProv_MAL AS (

SELECT IdTipoCuentaOperacion,IdTipoCuenta,IdTipoOperacion,Mascara,DescripMascara,

9 Digitos_Subcuentas, 5 Digitos_Proveedor

FROM [BDCLIENTE441700]..Cuentas_TiposCuentaOperacion

WHERE Mascara LIKE '%{IdProveedor}%' AND (LEN(REPLACE(Mascara,'{IdProveedor}','')) + 5)<>9)

UPDATE c SET c.Mascara = left(c.Mascara,3) + '0{IdProveedor}'

FROM Cuentas_TiposCuentaOperacion c

INNER JOIN TiposCuentaProv_MAL t ON c.IdTipoCuentaOperacion = t.IdTipoCuentaOperacion AND c.IdTipoCuenta = t.IdTipoCuenta 

AND c.IdTipoOperacion = t.IdTipoOperacion

El último mensaje devuelto por las comprobaciones previas nos sugiere que modifiquemos una propiedad de la base de datos.

Procederemos según se nos indica, estableciendo la opción CHECKSUM.

Ejecución Scripts Posteriores

En este paso se informa de la conveniencia de revisar el valor de ciertos parámetros en caso de que nos puedan afectar.

Recompilación

En este paso han aparecido 11 mensajes de tipo Revisión de Llamadas porque se han modificado los parámetros de determinadas storeds estándar durante el proceso de actualización.

El primer caso se trata de la stored PListas_Precios_Cli_ModifPrec_Personalizado que depende de PListas_Precios_Cli_ModifPrec. Debemos buscar la definición de la primera stored para asegurarnos que tiene los mismos parámetros con los que se le llama desde la segunda.

El siguiente mensaje corresponde con otra stored donde ocurre algo parecido a la stored anterior.

 Así que localizaremos las storeds implicadas y procederemos a solucionarlo como en el caso anterior.

El proceso personalizado TPV_Genera_Albaran_DesdeTicket_Personalizado carece de dos parámetros que sí que recibe la stored de la que depende   TPV_Genera_Albaran_DesdeTicket. Hay que añadirlos, así que copiamos de una y pegamos en la lista de parámetros de la otra, aplicando los cambios.

A continuación es conveniente revisar que los tipos de datos de los parámetros de las storeds anteriores coinciden, puesto que los mensajes nos advierten que han cambiado. En esta ocasión no encontramos diferencia entre ellos así que no hay nada que hacer al respecto.

En el caso del proceso personalizable PListas_Precios_Cli_ModifPrec_Personalizado sí que hay diferencia en el tipo de dato de los parámetros @Porcentaje, @PorcentajeAlquiler y @PorcentajeSeguro que están como float y deberían estar como en la stored padre, es decir, deberían ser T_Precio. Lo cambiamos.

Tras estos pasos, ya está finalizada la actualización completa de la base de datos del cliente a versión 4.4.2200 HF3.