[ubuntu-ar] [GUFA] Adodb.Connection

[Pablo Lillia]

El 20/03/14 08:09, francisco prieto escribió:
> Avance...
>
> El primer error que me data era este...
>
> No se encuentra la definición de clase ADODB.CONNECTION.
>
> Utilizando la aplicacion Winetricks,
>
> 1) le di aceptar a Select the defaults wineprefix...
> 2) seleccione Install a Windows DLL or component y aceptar
> 3) Seleccione MDAC28 y aceptar
>
> Con esto se me instalo Microsoft Data Access Component 2.8 sp1 y 
> tambien la 2.7.
>
> Luego de eso volvi a correr el sistema y ahora me da el siguiente error:
>
> Código de excepción OLE IDispatch 0 de ADODB.Connection: Provider 
> cannot be found. It may not be properly installed..
>
> Pero si corro sqlncli.msi me informa que esta instalado, con lo cual 
> debo pensar que aun falta otro componente...
>
> Sigo investigando,
>
> Saludos
> Pancho
>
>

Pancho,
si bien lo que te voy a comentar no va a solucionarte nada en lo 
inmediato, ¿evaluaste migrar a otra alternativa más actual y bien 
soportada, multiplataforma (y libre!) como Python, y a aplicaciones web?

TL;DR;

Se que comentaste que tenés muchísima experiencia con VFP. Sabrás que ya 
no tiene soporte, la última versión es del 2004, y luego solo fue 
actualizada en 2007, hace 6 años. Quedó en 32 bits, y no tiene intención 
MS de continuarlo. Cada vez serán mayores los problemas de 
compatibilidad, ni hablar de las complicaciones con Wine que es 
reimplementación de la API de win32 sobre Posix/Linux, sino que irán 
apareciendo cada vez más problemas con las versiones más recientes de 
windows y/o sql-server y cía.

Migrar no es fácil ni gratis, es una inversión que lleva tiempo y tiene 
su costo, incluso puede aterrar a más de uno. Pero si lo pensás desde el 
punto de vista de las oportunidades perdidas por las limitaciones de esa 
tecnología (cero seguridad, obsoleto, grandes limitaciones para crecer 
al crecer las instalaciones, etc), y de todos los dolores de cabeza y 
problemas de compatibilidad crecientes y altos costos de soporte de 
instalaciones que cada vez serán y son más sensibles a las 
compatibilidades... creo que se paga solo el invertir todo a cambiar de 
plataforma, aunque haya que aprender nuevos lenguajes y herramientas. Un 
día, empezarás a encontrar problemas insalvables, y se volverá cada vez 
más difícil y costoso mantener esos sistemas, y convencer al cliente de 
ello (y ni hablar de darle un buen resultado).

Te planteo Python porque es multiplaforma, y es uno de los lenguajes más 
amigables, fácil y rápido de aprender. Por tu experiencia previa, creo 
que puede ser ideal para tu caso. Hay muchas otras opciones de lenguajes 
y herramientas (PHP, Java, y un gran etc) que serán más o menos 
adecuadas para cada caso.

No descartes a las aplicaciones web de movida. Cuando se tiene demasiada 
experiencia con aplicaciones de escritorio, es normal el recelo creyendo 
que no podrán realizar el mismo tipo de interfaces de usuario ricas. 
Pero no es así. Hace tiempo que se pueden hacer UIs tan buenas o 
mejores, y con muchísimas ventajas operativas, de implementación, de 
mantenimiento, de seguridad, de portabilidad, y de un larguísimo etc. 
Eventualmente, para el control de algún dispositivo local que no pueda 
usarse por red, se puede hacer un pequeñísimo módulo de escritorio si 
conviene, pero las ventajas de las apps web son demasiado importantes 
como para descartarlas de plano, más con la diversidad de dispositivos y 
plataformas de hoy día.

En lo personal y si estuviera en una situación similar actualmente, 
dejaría en mantenimiento ínfimo y catatónico a las aplicaciones 
heredadas, haciéndolas correr como están sobre emuladores o lo que haga 
falta mientras se pueda, y pasaría a invertir todo el esfuerzo en migrar 
de plataforma cuanto antes y de forma planificada y coordinada. Tratar 
de adaptar las aplicaciones de una tecnología obsoleta, por más que haya 
sido muy útil y gauchita en su momento, es doble esfuerzo, de alto 
riesgo (de fracaso), y un alto costo, que te va a alejar del objetivo 
final. Hacer aplicaciones desde cero en la tecnología nueva traerán 
algunos nuevos bugs pero serán corregidos, y se habilitará hacer cosas 
imposibles antes, y con mucho menor esfuerzo al dominarse la nueva 
tecnología. Rescataría la parte del análisis y la experiencia (que es lo 
más valioso), y desecharía la mayor parte o todo el código. Incluso el 
modelo de datos, si están hechos "a la xbase" y sin normalización 
alguna, es la oportunidad justa para repensarlo seriamente.

Perdón por tan larga opinión. Es solo eso, una opinión más que puede 
servirte o no, aplicarse o no, sabiendo que es imposible a la distancia 
saber si te será útil, pero que sale desde la experiencia de otro 
programador que usó las mismas tecnologías o similares hace décadas atrás.

Saludos!
Pablo