Desarrollando desde la trinchera.

Estaba buscando una forma fácil de poder ejecutar en producción una validación de la estructura de la base de datos, para asegurarme que las tablas existen y que tienen todos los atributos de la versión que voy a instalar. Parece un problema menor o de fácil solución, pero en algunas instalaciones, las reorganización de las tablas no dependen de nosotros o hay mas personas que pueden cambiar la estructura de la base de datos, por lo que tener una forma de chequear que el programa se va a encontrar la base de datos esperada viene muy bien. Le agregué una opción al KBDoctor que genera varios scripts SQL para hacer algunas validaciones. La mas simple, recorre todas las tablas de la aplicación y todos los atributos de dicha tabla y genera un script del tipo: select attClave1, attClave2, attSec1, attSec2, attSec3 from Tabla where 1=0 No se tienen en cuenta los atributos formulas no redundantes e inferidos. De esta forma, si dicho script corre sin errores, existen grandes po...

Por la forma en que desarrollamos GeneXus, basados en conocimiento y no en la tecnología de moda, es común que tengamos algunas KB que fueron desarrolladas años atras, que aun sigan funcionando sin problemas. Esto es una ventaja enorme, pero también nos trae el problema de como hacer para que dicho codigo utilice las nuevas funcionalidades, para facilitar su mantenimiento.  Pongo un ejemplo concreto: Parametros con IN:, OUT: e INOUT:  En versiones viejas de GeneXus, todos los parámetros eran de entrada/salida. En versiones mas recientes, se puede especificar si los parámetros son de entrada o de salida, por lo que se evitan problemas de modificar un parámetro sin querer y queda mas claro que es lo que hace el objeto al tener especificado cuales parámetros son de entrada y cuales de salida.  Ademas el código generado, es mas compacto, se usa menos memoria, etc.  Teniendo tantas ventajas, es deseable poder cambiar todo el código viejo y obligar que ...