Explorando visual studio a la fuerza 2.0

Si ya lo se, el título de este post no es muy creativo, pero que le vamos a hacer, llevo un par de semanas fuertes experimentando con visual studio 2005, y creo que hay cosas que pensé que serían bastante más difíciles, pero un par como lo que comentaré que rayan en lo absurdo.

Estábamos comenzando a estructurar nuestros archivos en la base de datos del software de nuestra tesis, y bueno llevábamos un día perfecto porque avanzamos mucho y habíamos aprendido a como trabajar con los componentes que el compilador trae, lo que nos ahorraba muchas horas de trabajo y demasiadas lineas de código, pero en el momento menos pensado aparece un problemilla, este consistía en que nosotros compilábamos el software y lográbamos listar los datos de nuestra DB, y luego insertabamos cosas en ella a mano, cero atados, pero cuando intentamos hacerlo con los componentes nuevos, nos mandaba la mier... no se actualizaba la porquería.

Luego de cerca de 20 horas perdidas con este problemón y pensando que ya debiamos escribir el código a mano, lo que nos agregaba muuuuuchas líneas a nuestra aplicación y por supuesto mucho tiempo perdido, me puse a experimentar con la base de datos de prueba. En un principio también me dio error, por lo que ya creí que era un bug del compilador, desmoronado me puse a tirarle piedras al gato de la casa, pero luego hice una lesera, no importé la base de datos sino que la comencé a llamar desde la ubicación original, "eureca", funcionaba osea se actualizaba la base de datos, pero aún no sabía porque.
Indignado porque pense que tenía problemas con los permisos de la base de datos que habia creado y tendría que revisar todo, me puse a desarmarla, en ese intento dí con que el compilador al momento de generar la aplicación de prueba generaba una copia de la base de datos access en la carpeta bin/debug/ dentro de la misma solución y claro cuando yo hacía los cambios en la base de datos era esta la que se actualizaba. El problema es que dentro del compilador cuando uno miraba la base de datos conectada esta nunca variaba y era obvio porque esa es la que esta en la raiz de la solución, no en la carpeta de compilación, y bueno lo peor es que cada vez que uno recompilaba la base de datos en la carpeta de compilación se sobreescribia la base de datos de prueba con la original, por lo que la aplicación también parecía no funcionar.

Asi que más de 20 horas de trabajo perdido por una lesera, que si lo hubiese encontrado en alguna parte de todos los sitios que me daban recomendaciones sobre el código me hubiese ahorrado muchos problemas.

Resumiendo:

Cuando tenemos una base de datos access y la importamos a nuestra solución dentro del visual studio, los cambios que generamos en la base de datos de prueba al compilar solo permanecen alli hasta que volvemos a compilar la solución y además no se ven estos reflejados directamente desde visual por lo que es conveniente ir directamente a la carpeta bin/debug a averiguar que tal nos fue.

Ahora si no queremos pasar un mal rato con eso, mientras probamos podemos instalar la base de datos en cualquier parte y cuando la insertemos dentro de la solución no nos olividemos de NO IMPORTARLA, para los cambios se reflejen en todo momento, y ya cuando se quiera generar el programa terminado la importamos a nuestra solución como es debido y listo cuando se instale en el computador del usuario estará alli.