goto or not goto

Uno de los problemas que hemos tenido siempre, al trabajar con Access como herramienta de desarrollo, es el control de versiones. Si se está trabajando sobre el mismo proyecto varias personas o tienes la suerte de trabajar con la versión 2007, es más recomendable trabajar con las Access Developer Extensions . (siempre que no te importe trabajar con Visual Source Safe) Pero si todavía estás trabajando con versiones anteriores o no puedes o quieres trabajar con Visual Source Safe todavía estás de suerte: Hay un par de métodos no documentados Application.SaveAsText y Application.LoadFromText que nos ayudarán muchísimo. Os dejo unos links sobre utilidades que hacen uso de estas funciones. La idea en todos ellos es la misma: recorrer la lista de formularios, consultas, informes, módulos, macros e ir guardando los objetos en ficheros de texto: http://iridule.net/cu/index.htm (busca la entrada Object as Text casi abajo) http://www.ffdba.com/downloads/Save_MDB_Objects_As_Text...

¿A quién no le ha tocado mantener (y extender) aplicaciones heredadas que llevan nosecuantos años purulando por la empresa? ¿Qué hacer cuando hay que agregar una nueva funcionalidad a la aplicación? Pues depende... ¿El lenguaje en que se desarrolló la aplicación se sigue manteniendo? ¿Las nuevas funcionalidades requeridas están soportadas por el lenguaje / plataforma de desarrollo? El qué hacer también dependerá del tamaño, nº de usuarios de la aplicación y del presupuesto disponible para migrarla a otra tecnología: como siempre, del ROI El caso que me ocupa en estos días (más bien meses): Aunque en mi empresa empezamos a desarrollar en .net allá por el 2004, todavía seguimos manteniendo aplicaciones VBA desarrolladas antes y durante aquella época. ¿VBA? Si, muchas de las aplicaciones desarrolladas eran cliente/servidor con un sql server como servidor y Access como cliente. Nos han pedido ampliar la funcionalidad de la aplicación que estamos manteniendo. Podríamos haber desar...

Sí, claro: tengo todos los literales en cadenas de recursos, muestro las fechas según la referencia cultural del usuario, utilizo string.Compare para compar 2 cadenas,... Incluso tengo en cuenta el uso horario cuando un usuario introduce una fecha y trabajo con caracteres unicode para admitir idiomas asiaticos. Ves como es internacionalizable. Ah, y por supuesto, tengo en cuenta las diferentes monedas y sus tipos de cambio. Pues NOOO.... Veamos, cumple con los requisitos mínimos para serlo. Pero eso no quiere decir que esté preparada para desplegarla en cualquier sitio del mundo. La referencia cultural va más alla de las simples normas de formateo de fechas y números. Se debe tener en cuenta la legislación de cada país e incluso las costumbres de diferentes zonas. Es decir, dentro de la lógica de nuestra aplicación, deberemos incluir reglas de negocio que varían dependiendo del pais. Veamos un ejemplo: Actualmente estamos montando un sistema que automatiza la creación de usuarios en el...