¿Te has parado a pensar como trabajar con SQL Server CE 4.0 en un proyecto en el que intervengan 2 o más programadores?
Digo esto porque si quieres tener tus bases de datos .sdf bajo control de código fuente, tienes un problema.
El primero es que el atributo de sólo lectura impide abrir una conexión contra la base de datos, así que cuando alguno de los programadores haga un check-in para desproteger el fichero y poder trabajar… a partir de ese momento el resto de programadores no podrán trabajar, así de sencillo y así de triste.
En nuestro caso, lo hemos resuelto no agregando este tipo de ficheros (.sdf) al control de código fuente, pero aun así, todavía tenemos un problema más.
Ahora sucede que queremos trabajar con una sola versión del fichero .sdf (sobre todo para que los cambios que realice uno de nosotros sean visibles para el resto), así que movemos el fichero a un carpeta compartida en la red. Pues bien, en tiempo de ejecución no hay ningún problema y nuestra cadena de conexión es similar a \\directorio\data.sdf y todo funciona correctamente. El problema está que por otro lado, Visual Studio ha decidido que no quiere abrir el fichero .sdf en el explorador de servidores (y como supondrás, esto significa que no podemos editar el fichero .sdf). He probado con el recurso compartido, con una unidad mapeada, con subst… pero nada.
Si quieres pruebas, hay van:
La conclusión es que trabajamos con un fichero .sdf en una ubicación de red pero cuando hay que realizar cambios en la estructura de tablas, el programador 1 dice “perdón, tengo que hacer cambios, así que me copia a local el fichero .sdf para poder abrirlo en Visual Studio, por favor, esperar a que termine…”, mientras el resto de programadores se fuman un cigarrito, se toman un refresco, etc. Cuando el programador 1 termina de hacer sus cambios vuelve a decir “Ya he terminado, sobreescribo el fichero .sdf de la red, ya podéis trabajar” y entonces el resto de programadores vuelven al tajo… Como verás, todo es muy científico y estamos muy contentos de trabajar con SQL Server CE 4.0 (es ironía, lo captas, ¿verdad?)
La solución propuesta no es mía y parece ser la norma, http://social.msdn.microsoft.com/Forums/en-SG/sqlce/thread/669f7bd3-d507-4e3f-b291-df8d5a51ae14
Yo, personalmente, me estoy empezando a hartar del tema y creo que exploraremos otras soluciones como MySql o cualquier otro gestor de base de datos serio, en vez de SQL Server CE 4.0. La experiencia de 2 proyectos ha sido bonita, educativa, pero la conclusión está clara… SQL Server CE 4.0 NO ha venido para quedarse!
Si quieres más motivos por los que SQL Server CE me saca de quicio, puedes leer estos otros post (que conste que lo he intentado, he defendido SQL Server CE 4.0 frente a colegas en el trabajo, he escrito posts, pero aun así…)
IsSys en SQL Server Compact 4.0 es peligroso!
Ficheros bloqueados de SQL Server CE 4.0 en proyecto ASP.NET
Soporte del diseñador de Entity Framework para SQL Server Compact Edition 4.0
Un saludo!
No hay comentarios:
Publicar un comentario