El cambio de dAcli7 desde Access a SQL Server

Caso real de optimización en dAcli: de Access a SQL Server

Migración desde Access a SQL Server

Durante años convivimos con un problema que muchos sistemas legacy conocen demasiado bien: la base de datos funcionaba… hasta que dejaba de funcionar.

Y cuando dejaba de funcionar, no era un bug menor. Era algo peor: corrupción de datos.

El contexto real: software en condiciones no ideales

dAcli es un sistema de gestión utilizado en laboratorios clínicos en Venezuela, un entorno donde existe una variable crítica que muchas arquitecturas no contemplan: los cortes eléctricos.

Durante años, el sistema utilizó Microsoft Access como motor de base de datos, lo que terminó siendo un punto débil en este contexto.

El problema: Access y apagones

Cada vez que ocurría un corte eléctrico, existía una probabilidad real de que la base de datos:

• Quedara corrupta.
• No pudiera abrirse.
• Obligara a restaurar respaldos.

Esto no era un evento aislado. Era recurrente.

La única defensa posible era aumentar la frecuencia de respaldos, lo que generaba otros problemas operativos:

• Pérdida de datos recientes.
• Interrupciones en el laboratorio.
• Reinicios periódicos de la base de datos.

Incluso con pocos usuarios concurrentes (5 o 6), los problemas de concurrencia eran constantes.

El parche: manejar concurrencia desde el código

Para mitigar estos problemas, se implementaron soluciones a nivel de código:

• Bloqueos manuales.
• Validaciones adicionales.
• Control de acceso a datos.

Estas soluciones redujeron conflictos, pero introdujeron un nuevo problema: lentitud generalizada del sistema. Con el tiempo, el código comenzó a crecer de forma desordenada.

20 años de código acumulado

El sistema acumuló una gran cantidad de código innecesario:

• Funciones no utilizadas.
• Formularios huérfanos.
• Lógica duplicada.
• Loops innecesarios.
• Implementaciones antiguas mal diseñadas.

Era imposible mejorar el rendimiento sin enfrentar este problema directamente.

El proceso: limpieza manual y refactorización

Se realizó un proceso completo de limpieza de código, de forma manual:

• Eliminación de código muerto.
• Simplificación de lógica.
• Reestructuración de módulos.

Este proceso duró aproximadamente seis meses, trabajando en horarios nocturnos y fines de semana.

Durante este tiempo, múltiples funcionalidades dejaron de funcionar temporalmente. Fue un proceso iterativo de ruptura y reconstrucción.

La decisión clave: migrar a SQL Server

Paralelamente, se decidió migrar el sistema a Microsoft SQL Server.

La migración no fue automática. Se realizó de forma manual, aprovechando para mejorar la estructura de datos.

Cambios realizados

• Normalización de la base de datos.
• Cambio de tipos de datos.
• Creación de índices.
• Reescritura de consultas.
• Centralización del acceso a datos en una sola capa.

Se creó una clase que concentra todas las consultas, permitiendo desacoplar el sistema del motor de base de datos.

Function generarCodigo(tabla As String, CampoClave As String)
    Dim rs As New ADODB.Recordset
    rs.Open "SELECT MAX([" & CampoClave & "]) FROM [" & tabla & "]", conexion
    If Not IsNumeric(rs(0)) Then
        generarCodigo = 1
    Else
        generarCodigo = rs(0) + 1
    End If
End Function

Public Function DSQL(ByVal consultaSQL As String) As ADODB.Recordset
    Dim rs As New ADODB.Recordset
    On Error GoTo errorHandler
    rs.Open consultaSQL, MPrincipal.base, adOpenStatic, adLockOptimistic, adCmdText
    Set DSQL = rs
    Exit Function

errorHandler:
    Dim ErrorDescripcion
    ErrorDescripcion = Err.Description & vbCrLf & "#" & Err.number & " source:" & Err.Source
    MPrincipal.Log "sql", "Error:" & ErrorDescripcion & vbCrLf & consultaSQL
    If MPrincipal.RunningInVB Then
        Debug.Print consultaSQL
        MsgBox ErrorDescripcion & vbCrLf & consultaSQL, vbCritical
        Debug.Assert True
    End If
    MsgBox "No puedo completar la operacion"
End Function

Public Function Execute(ByVal consultaSQL As String, Optional silence As Boolean = False) As Boolean
    On Error GoTo errorHandler
    MPrincipal.base.Execute consultaSQL
    Execute = True
    Exit Function

errorHandler:
    Debug.Print Err.Description & vbCrLf & consultaSQL
    MPrincipal.Log "sql", Err.Description & vbCrLf & consultaSQL
    If Not silence Then
        MsgBox "Accion no realizada", vbCritical
    End If
    Execute = False
End Function

Function EscaparComillas(ByVal consultaSQL As String) As String
    EscaparComillas = consultaSQL
    Exit Function
    Dim partesConsulta() As String
    Dim i As Integer
    
    partesConsulta = Split(consultaSQL, " ")
    
    For i = LBound(partesConsulta) To UBound(partesConsulta)
        If partesConsulta(i) Like "*'*" Then
            partesConsulta(i) = Replace(partesConsulta(i), "'", "''")
        End If
    Next i
    
    EscaparComillas = Join(partesConsulta, " ")
End Function

Con la nueva arquitectura, se aplicaron mejoras clave:

• Uso de stored procedures.
• Implementación de caché.
• Reducción de consultas redundantes.
• Optimización de consultas pesadas.
• Reducción del tráfico de red.

El sistema dejó de depender de lógica distribuida en el cliente y pasó a aprovechar mejor el motor de base de datos.

Resultados

Antes

• Lentitud constante.
• Bloqueos frecuentes.
• Corrupción de bases de datos.
• Reinicios periódicos.

Después

• Fluidez general del sistema.
• Consultas rápidas.
• Estabilidad operativa.
• Eliminación práctica de corrupción por apagones.

El cambio fue significativo tanto a nivel técnico como operativo.

Impacto en clientes

Actualmente:

• Más del 90% de los laboratorios han migrado.
• El sistema supera los 200 clientes.
• Los clientes que inicialmente dudaban por costos terminaron adoptando la nueva arquitectura.

La diferencia en estabilidad y rendimiento justificó completamente el cambio.

Lecciones aprendidas

• Los problemas de rendimiento muchas veces son problemas de arquitectura.
• Los parches técnicos generan deuda acumulativa.
• La limpieza de código es esencial en sistemas de larga vida.
• Los motores de base de datos tienen límites claros según el contexto.
• La estabilidad es una característica crítica en entornos reales.

Conclusión

Este proceso no fue simplemente una optimización. Fue una evolución completa del sistema.

dAcli pasó de ser un sistema funcional a convertirse en una plataforma estable y confiable para la operación diaria de laboratorios clínicos.

En entornos donde la continuidad operativa es crítica, este tipo de decisiones técnicas marcan la diferencia.

Página web de dAcli: www.dacli.com