Perdonad que discrepe, pero no cambio el ADO por nada del mundo
Ha sido mi salvación para adaptarme a nuevos paradigmas. El único problema que no he sido capaz de solucionar es cuando se pierde la conexión a la base de datos (se haya caido el servicio) que no pasa jamás, pero alguna vez en la empresa se hace por motivos ... (que no vienen a cuento) y entonces saltan 10.000 errores
)) , pero es la única pega y si todo va como debe de ir, jamás falla.
Ventajas, bajo mi punto de vista:
- No hay que definir nada en la working especificamente.
- Permite conectarse con ConnectionString, por lo que puedo cambiar de base de datos sin tocar código.
- da igual la complejidad de la select, con un string la construyes sin limitaciones.
- trabajar con el recordset generado es muy fácil y extraer la información igualmente.
- Un problema, NO PUEDEN VENIR CAMPOS NULL si los vas a almacenar en un numérico, se soluciona con un CASE (sqlserver) en la propia select.
Todo lo expuesto para utilizarlo con el control ADO que viene con el NetCobol.
Para algún caso específico también creo el objeto, por ejemplo INSERT MASIVOS o ejecución de algún procedimiento almacenado o función.
Como consejo final, la decisión que tomé de utilizar bbdd y solo dejar los indexados para ficheros temporales de trabajo, ha sido la mejor que he tomado en mucho tiempo.