Publicando Sql Server Ce 4 con Entity Framework en un hosting compartido

Aunque he publicado anteriormente entradas sobre este mismo tema, lo cierto es que nunca había publicado un sitio web en un hosting compartido que, además de utilizar Sql Server Ce 4, utiliza también Entity Framework.

Recientemente he tenido que desarrollar un proyecto con estas características y me ha parecido oportuno escribir un pequeño resumen de ineludibles pasos que hay que completar si queremos ver funcionar este particular binomio en un entorno de hosting compartido.

Para este post asumo que tienes un sitio web (no confundir con aplicación web) que utiliza Sql Server Ce 4 y Entity Framework y que funciona correctamente en tu máquina local.

Partiendo de esta base, será necesario realizar cambios tanto en tu proyecto local como cambios en el servidor de publicación.

Los pasos a completar en tu proyecto local son los siguientes:

• Eliminar la referencia al ensamblado System.SqlServer.Ce que está apuntado al GAC. Esto es porque no podemos asumir que en el servidor de despliegue esté instalado Sql Server Ce 4.
• Copiar en el directorio Bin todo el contenido de la carpeta C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private
• Agregar el siguiente código al fichero web.config de la raíz del sitio web

<runtime>     <assemblyBinding appliesTo="v2.0.50727" xmlns="urn:schemas-microsoft-com:asm.v1">       <dependentAssembly>         <assemblyIdentity name="System.Data.SqlServerCe" publicKeyToken="89845dcd8080cc91" culture="neutral"/>         <bindingRedirect oldVersion="4.0.0.0-4.0.0.1" newVersion="4.0.0.1"/>       </dependentAssembly>     </assemblyBinding>   </runtime>     <system.data>     <DbProviderFactories>       <remove invariant="System.Data.SqlServerCe.4.0"/>       <add name="Microsoft SQL Server Compact Data Provider 4.0" invariant="System.Data.SqlServerCe.4.0" description=".NET Framework Data Provider for Microsoft SQL Server Compact" type="System.Data.SqlServerCe.SqlCeProviderFactory, System.Data.SqlServerCe, Version=4.0.0.1, Culture=neutral, PublicKeyToken=89845dcd8080cc91"/>     </DbProviderFactories>   </system.data>

 

En este momento tu proyecto en local debería seguir funcionando con normalidad y no percibir el cambio realizado.

Los pasos a completar en el servidor del hosting compartido son los siguientes:

• Conceder permisos de “Modificar” en el directorio App_Data a la cuenta Plesk IIS WP User (IWAN_plesk(default))
• Conceder permisos de “Modificar” en el directorio Bin a la cuenta Plesk IIS WP User (IWAN_plesk(default))

En realidad, la cuenta de usuario a la que hay que conceder los permisos es la cuenta que este utilizando el worker process de ASP.NET. En mi caso y utilizando el panel de control Parallels Plesk Panel, la cuenta de usuario predeterminada es la anteriormente citada.

Cómo ultimo tip, te diré que cuando todo esté funcionando y quieras volver a publicar tu aplicación, lo más seguro es que ciertos ensamblados de Sql Server Ce estén bloqueados por el proceso w3wp.exe y no se permite la sobreescritura de los mismos. Asumiendo que no puedes ni reiniciar el grupo de aplicaciones ni tampoco el servidor web (la única solución que desbloqueará los mencionados ficheros), la única solución digna que he encontrado es no copiar en siguientes publicaciones todos los directorios y ficheros que copiamos en el directorio Bin para que funcionara correctamente Sql Server Ce 4.

En cualquier caso y a partir de aquí, ya puedes utilizar felizmente Sql Server Ce 4 y Entity Framework en tu hosting compartido, sin preocuparte si está o no instalado Sql Server Ce en el servidor.

Un saludo!

Equivalencia de tipos SQL Server Compact Edition 4.0 en Entity Framework

En este otro post, vimos la equivalencia entre tipos de datos SQL Server 2008 R2 y tipos de .NET en el modelo de Entity Framework.

Ahora es el turno de ver la equivalencia con los tipos de datos de SQL Server Compact Edition 4.0.

Siguiendo el mismo guión que en el primer post de equivalencias, aquí va el script para crear una tabla en SQL Server CE 4.0 con los todos los tipos disponibles.

CREATE TABLE [development_DataTypes] (

  [Cbiginit] bigint NOT NULL

, [Cbinary] binary(100) NULL

, [Cbit] bit NULL

, [Cdatetime] datetime NULL

, [Cfloat] float NULL

, [Cimage] image NULL

, [Cint] int NULL

, [Cmoney] money NULL

, [Cnchar] nchar(100) NULL

, [Cntext] ntext NULL

, [Cnumeric] numeric(18,0) NULL

, [Cnvarchar] nvarchar(100) NULL

, [Creal] real NULL

, [Crowversion] rowversion NULL

, [Csmallint] smallint NULL

, [Ctinyint] tinyint NULL

, [Cuniqueidentifier] uniqueidentifier NULL

, [Cvarbinary] varbinary(100) NULL

);

GO

ALTER TABLE [development_DataTypes] ADD CONSTRAINT [PK_development_DataTypes] PRIMARY KEY ([Cbiginit]);

GO

Y ahora la equivalencia prometida:

SQL Server Compact Edition 4.0	.NET
biginit	Int64
binary	Binary
bit	Boolean
datetime	DateTime
float	Double
image	Binary
int	Int32
money	Decimal
nchar	String
ntext	String
numeric	Decimal
nvarchar	String
real	Single
rowversion	Binary
smallint	Int16
tinyint	Byte
uniqueidentifier	Guid
varbinary	Binary

 

Un saludo!.

 

Soporte del diseñador de Entity Framework para SQL Server Compact Edition 4.0

Aunque en mi oficina echan pestes de SQL Server Compact Edition 4.0, yo sigo queriendo darle una oportunidad y quiero ver cómo trabajar con esta base de datos y ADO.NET Entity Framework.

El problema está en que para todos los ejemplos que hago siempre creo un nuevo proyecto de consola, y aunque puedo agregar un fichero de base de datos de SQL Server CE 4.0, cuando después agrego un modelo de datos de entidades ADO.NET, en el asistente nunca me aparece disponible la conexión a mi recién creado fichero .sdf y tampoco puede agregar una nueva conexión a SQL Server CE 4.0 (sólo aparece 3.5).

Entonces ¿Cómo trabajo con SQL Server CE 4.0 y ADO.NET Entity Framework?

Pues después de googlear un poco he descubierto que para SQL Server CE 4.0, Visual Studio 2010 sólo da soporte para el diseñador visual del modelo EDM para proyectos de tipo web (tanto un sitio web como una aplicación web).

Parece que hay posibles soluciones si estás trabajando en un proyecto de Windows Forms o de consola, pero lo cierto es por ahora no te estoy interesado en ver si la solución propuesta es o no válida.

Lo cierto es que sigo pensando que la gente de Microsoft ha hecho un gran trabajo con SQL Server CE 4.0… pero también un trabajo incompleto… y juro y perjuro que estoy intentando darle cancha a pesar de todas las incomodidades que presenta.

El enlace a la pregunta y respuesta en stackoverflow es este.

Un saludo!.

SQL Server CE 4.0 NO ha venido para quedarse!

¿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!

NText en Sql Server Ce 4.0

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!

IsSys en SQL Server Compact 4.0 es peligroso!

Hoy hemos recibido una inesperada sorpresa cuando hemos visto que Dormammu también anida en la entrañas de SQL Server CE 4.0.

Si quieres comprobarlo tú mismo, basta con que crees una nueva base de datos SQL Server CE 4.0 y agregues un campo a una tabla con un campo cuyo nombre comience por el literal ‘IsSys’.

Por ejemplo, en nuestro caso, tenemos una tabla [Users] con un campo [IsSystem], pues bien, comienza la fiesta…

Con la herramienta oficial de Microsoft (digo oficial, pero realmente quiero decir la herramienta que un par de becarios desarrollaron en un par de días… con todo el respeto a los becarios) esta columna no se ve, está missing, bueno está missing sólo en algunos sitios…

·         Se ve cuando editamos el esquema de la tabla

·         NO se ve cuando mostramos datos de la tabla

·         NO se ve en la conexión de datos desde el explorador de servidores

Para complicarlo aún más, si en vez de “mostrar datos de la tabla”, creamos una nueva consulta y seleccionamos la tabla [Users], aparece lo siguiente (sigue perdida la columna):

Sin embargo, sí podemos escribir la siguiente consulta, pero el campo aparece como de sólo lectura… yo no entiendo nada…

Sin embargo, si utilizamos la herramienta SQL Server Compact Toolbox de ErikEJ, todo funciona correctamente ¿Por qué no contrata Microsoft a ErikEJ?

Finalmente, mi recomendación (imposición) está clara: No utilices el literal IsSys como comienzo en el nombre de un campo en una base de datos SQL Server CE 4.0.

Un saludo!

NText en Sql Server Ce 4.0

Hoy me han preguntado en el blog como poder grabar un texto de más de 4000 caracteres en una base de datos Sql Server Ce 4.0.

Como me dice el autor del comentario, no tenemos disponible el tipo de datos nvarchar(max), así que la única solución que veo es declarar el campo ntext (que aunque después podría darnos guerra, por lo menos podremos grabar nuestra “super-cadena” de más de 4000 caracteres…)

Pues bien, tengo buenas y malas noticias.

Las malas son que utilizando System.Data.Common (factoría de proveedores) yo no encuentro como hacerlo, es decir, la equivalencia del tipo ntext de CE es System.Data.DbType.String si estamos trabajando con System.Data.Common. Y en este caso, el tamaño máximo de la cadena asignada es 4000. Si intentamos poner una cadena de tamaño superior, no falla pero trunca el valor al grabarlo en la base de datos. De hecho, aquí hay alguien que pregunta por esto mismo, pero como la solución (si es que la hay) está colgada en experts-exchange.com y es de pago, pues me voy a quedar con las ganas y voy a posponer este problema, rezando porque ningún cliente tenga la necesidad de grabar más de 4000 caracteres en las aplicaciones que nos piden en la empresa ;-)

Las buenas noticias son que si utilizamos el proveedor nativo de CE (en vez de la factoría de proveedores) y un SqlCeParameter, sí que podremos grabar más de 4000 caracteres en un campo de tipo ntext.

Por ejemplo, tengo en mi disco un fichero LIBRO.TXT (que literalmente tiene dentro un libro con “chorrocientos mil” caracteres) y no hay problema en guardarlo de este modo…

        Dim cnn As New System.Data.SqlServerCe.SqlCeConnection

        cnn.ConnectionString = "Data Source=|DataDirectory|\MIDB.sdf"

        cnn.Open()

        Dim cmd As New System.Data.SqlServerCe.SqlCeCommand

        cmd.CommandText = "UPDATE Ficheros SET Comentario = @Comentario"

        Dim prm As New System.Data.SqlServerCe.SqlCeParameter

        prm.ParameterName = "@Comentario"

        prm.SqlDbType = Data.SqlDbType.NText

        prm.Value = System.IO.File.ReadAllText("C:\LIBRO.txt")

        cmd.Parameters.Add(prm)

        cmd.Connection = cnn

        cmd.ExecuteNonQuery()

        cmd.Dispose()

        cnn.Dispose()

 

Espero haber contestado con esto a la pregunta del blog, pero en cualquier caso es otro tip a sumar a esa gran decisión de ¿Sql Server CE 4.0 en ASP.NET Sí o No?

Un saludo!.

Más experiencias con Sql Server CE 4.0 y ASP.NET

Siguiendo en la línea de los últimos posts, hoy voy a hablar sobre… ¡sorpresa! ¡SQL Server CE 4.0! ;-)

Simplemente son unos tips que me han ocurrido hoy y quería compartirlos.

En SQL Server (la versión de los niños mayores) es perfectamente válida este sentencia:

UPDATE Tabla SET Nombre = Valor FROM Tabla

Sin embargo, en CE la misma consulta nos arroja el siguiente error:

Error al analizar la consulta. [ Token line number = 1,Token line offset = 60,Token in error = FROM ]

Esto quiere decir que a CE no le gusta el FROM, así que la consulta anterior quedaría:

UPDATE Tabla SET Nombre = Valor

Por otro lado y aunque no falla, la sentencia SELECT @@IDENTITY no devuelve ningún valor (al menos a mí no me lo devuelve), así que si quiero saber cual es el último valor de identidad insertado hay que lanzar una consulta como la siguiente:

SELECT autoinc_next - 1 FROM information_schema.columns WHERE table_name = 'MITABLA’ AND autoinc_seed > 0

Ya os iré contando mis venturas y desventuras con CE 4.0 en ASP.NET.

Un saludo!

Ficheros bloqueados de SQL Server CE 4.0 en proyecto ASP.NET

Como sabréis si habéis leído anteriores post de mi blog, estamos inmersos en un proyecto de sitio web ASP.NET con SQL Server Compact Edition 4.0. Después de haber resuelto como desplegar el proyecto en un hosting compartido que no tiene instalado el runtime de SQL Server CE (utilizando también de forma opcional el espacio de nombres System.Data.Common y su factoría de proveedores), ahora nos encontramos con un nuevo problema para el que, con franqueza, no hemos encontrado una solución definitiva.

El problema está es que cuando ejecutamos una página que tiene acceso al fichero .sdf del proyecto (la base de datos de SQL CE), el proceso w3wp.exe (el worker process de ASP.NET) carga el runtime de SQL CE y cuando queremos sobreescribir el directorio \bin de nuevo en el servidor (porque por ejemplo estamos actualizando nuestra aplicación o estamos actualizando la propia versión de SQL CE – cuando llegue el momento y suba de versión, etc.), ciertos ficheros de ese runtime de SQL CE están bloqueados y no permiten la sobreescritura.

Si recordamos, tuvimos que copiar en el directorio \bin de nuestro sitio web todo el contenido de la carpeta C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private (excepto el fichero System.Data.SqlServerCe.Entity.dll). Pues bien, cuando queremos volver a subir nuestra aplicación al hosting, obtenemos un “bonito” bloqueo (esto también ocurre cuando copiamos a través de ftp, pero para el ejemplo estoy copiando en un servidor de la oficina utilizando directamente una carpeta compartida).

Si vemos en el servidor que está ocurriendo con el programa Unlocker, podemos ver que el proceso w3wp.exe tiene “pillados” algunos ficheros del runtime de SQL CE.

Para desbloquearlos sólo hemos encontrado las siguientes formas (siempre sin utilizar Unlocker o parecidos que nos parecen un pelín agresivo y además resultan inviable en un entorno de hosting compartido donde no tenemos acceso físico a la máquina):

• Reiniciar el servicio “Servicio de publicación World Wide Web”.
• Reciclar el grupo de aplicaciones (AppPool) de nuestra aplicación.

De hecho, el kit de la cuestión es tirar abajo el proceso w3wp.exe, así que en líneas generales, mientras lo consigas cualquier método es válido.

Si estás pensando que modificando el fichero web.config también funcionará… pues va a ser que no. Esto es porque no hay que confundir el AppPool (grupo de aplicaciones), que es quién levanta el proceso w3wp.exe, con el AppDomain (dominio de la aplicación). Si modificas el fichero web.config lo que se reiniciará será el AppDomain (igual que si modificas el fichero global.asax, etc.). Puedes ver más información en el enlace siguiente http://stackoverflow.com/questions/302110/what-causes-an-application-pool-in-iis-to-recycle

Claro está que una solución sería no copiar el directorio \bin completo cada vez que publiquemos, pero con sinceridad quiero despreocuparme de ello y no tener que recordar cada vez que subo que tengo que “excluir” ciertas carpetas y ficheros de mi directorio \bin. De este modo, la única solución digna que hemos encontrado pasa por ser nosotros mismos quienes reiniciemos el grupo de aplicaciones de nuestra aplicación desde el mismo código de nuestra aplicación, y en ese preciso instante (y antes de que nadie pida una página con acceso nuestro fichero .sdf y vuelva a dejar pillado los ficheros), subir rápidamente… La verdad es que no muy científico pero ¡no vemos otra!

Para reiniciar el grupo de aplicaciones desde código, he encontrado los siguientes enlaces. Aún no he probado este método, pero estoy en ello y será “página obligada” en cualquier proyecto ASP.NET con SQL CE 4.0

http://www.codeproject.com/KB/aspnet/AppPoolRecycle.aspx

http://terrapinstation.wordpress.com/2008/06/12/restart-iis-application-pool-from-aspnet-page/

http://www.logue.com.ar/blog/2008/02/find-and-recycle-current-application-pool-programmatically-for-iis-6/

Por otro lado, también tengo que decir (y con profunda amargura) que me estoy encontrado otros problemas con SQL CE 4.0 que me están dejando un mal sabor de boca (ya sé que CE no es SQL Express, pero en mi opinión la gente de Microsoft podía haber hecho algo más por facilitar la vida a los desarrolladores…)

• No soporta el uso de TransactionScope. Más info aquí. Básicamente CE no soporta transacciones anidadas, y eso y TransactionScope no se llevan bien…
• No se puede cambiar el nombre de una tabla sino es a través del complemento SQL Server Compact ToolBox.
• No se puede cambiar el nombre de un campo.
• No se puede cambiar el orden de los campos.
• No se puede modificar la identidad (identity) para un campo en una tabla ya creada.
• No se puede conectar nuestra base de datos con ninguna versión de SSMS (Sql Server Management Studio).
  Cuidado con el complemento SQL Server Compact ToolBox porque sólo tiene un editor de SQL y se perderán los cambios si se genera alguna SQL automáticamente (clic derecho en tabla, por ejemplo). Además de que el editor no está muy logrado en lo relativo a deshacer, seleccionar, etc.

En los próximos días iré contando más experiencias con CE, pero por ahora estoy en ese momento de indecisión, que no sabría si me gusta o no me gusta…

Un saludo!