none
Bases de datos, SQL Server y licencias RRS feed

  • Pregunta

  • Hola, os cuento mis dudas. Tengo que desarrollar una aplicación de gestión, no muy grande, clientes, gestión de caja, etc...
    La aplicación en principio será monopuesto, pero es posible que evolucione a dos puestos, sin servidor, compartiendo uno de los puestos la base de datos.
    La haré con C# y Visual Studio 2008, pero no se qué base de datos elegir. En todas las aplicaciones que he hecho antes he utilizado un fichero de Access como base de datos.

    Mis dudas son: Si uso un fichero de access como base de datos para desarrollar la aplicación ¿el cliente final debería tener licencia de Access (Office) para ejecutar la aplicación legalmente?
    ¿Qué otra base de datos es adecuada para esta aplicación? He pensado en SQL Compact Edition , pero me surgen las mismas dudas ¿tendría que instalar el cliente final algo más aparte de mi aplicación? ¿tendría que instalar SQL Compact Edition o algo así en su equipo? ¿necesitaría alguna licencia para poder usar SQL Compact Edition? ¿Soporta SQL Compact Edition las clases Entity mediante VS2008 y DLINQ?

    Descarto SQL Server, porque me suena a algo más grande, algo para bases de datos alojadas en un servidor y que las aplicaciones se ejecuten contra el servidor, ¿me equivoco?
    Quizás también tendría que evaluar SQL Express Edition, ¿no?
    Cómo véis no lo tengo nada claro, y me preocupa que el cliente final vea incrementado el coste de su aplicación debido a tener que adquirir una licencia para base de datos a parte de tener que pagar mi software.

    Un saludo y muchas gracias por adelantado
    viernes, 5 de junio de 2009 9:25

Todas las respuestas

  • Para usar una base de datos Access no necesitas licencia. En realidad, aunque hablamos de "base de datos Access", el programa en C# solo llama al JET Engine, que es de uso gratuito (se instala descargando MDAC desde la web de Microsoft si necesitas usarlo en un equipo que no lo tenga ya instalado). No hace falta que el Access esté instalado en ningún equipo.

    Sql Compact Edition NO te sirve para lo que quieres, ya que solo funciona en monopuesto.

    No descartes Sql Server. Tienes la versión Express que es gratuita, sencilla de instalar y muy potente. Se puede instalar en uno de los PCs, que actúa de servidor para todos los demás (igual que si usas Access necesitas que un PC actúe de servidor compartiendo el archivo .mdb).

    viernes, 5 de junio de 2009 10:33
  • Pues estaba haciendo pruebas con SQL Compact Edition y la primera sorpresa que me he llevado es que en Visual Studio 2008 cuando arrastro una tabla desde el Explorardor de Servidores hacia el Object Relational Designer , con la intención de que me cree la correspondiente Entity Class de forma automática, me dice: Los objetos seleccionados usan un proveedor de datos no admitido .

    Lo del monopuesto en realidad no me preocupa tanto; el software quizás se use en otro puesto, pero no de forma simultánea, con lo que sería suficiente compartir el archivo de la base de datos como si de una Access se tratase. Por lo que he leído al fin y al cabo una base de datos SQL Server Compact Edition no es más que un fichero sdf

    Lo que si me preocupa es no poder usar DLINQ, o tener que usarlo "a mano ", sin las ayudas de VS2008 para crear las entity set y temas como el DataBinding.

    SQL Server Express Edition: Tiene buena pinta, es gratis. El problema es que la instalación de la aplicación se complica, pues tengo que instalar primero el SQL Express y luego la aplicación. Además en comparación con SQL Compact los recursos utilizados son demasiados. SQL Express ocupa 200Mb y es un servicio, mientras que SQL Compact usa 2Mb y es un fichero, y se puede instalar a la vez que la aplicación. ¿Me equivoco en algo?

    ¿Con SQL Express Edition no tendré problemas para crear las Entity classes arrastrando y soltando? Con SQL Server 2005 (que viene con Visual Studio 2008) no tengo ningún problema.

    No se, parece que me parece "demasiado" tener que instalar un servidor de bases de datos o un servicio para luego acceder a una base de datos en local , con una aplicación tan simple.

    Gracias por tu ayuda, Alberto
    viernes, 5 de junio de 2009 11:11
  • Pues estaba haciendo pruebas con SQL Compact Edition y la primera sorpresa que me he llevado es que en Visual Studio 2008 cuando arrastro una tabla desde el Explorardor de Servidores hacia el Object Relational Designer , con la intención de que me cree la correspondiente Entity Class de forma automática, me dice: Los objetos seleccionados usan un proveedor de datos no admitido .
    Efectivamente, si quieres usar las herramientas automaticas estás limitado a Sql Server, en cualquiera de sus versiones menos la Compact.
    Lo del monopuesto en realidad no me preocupa tanto; el software quizás se use en otro puesto, pero no de forma simultánea, con lo que sería suficiente compartir el archivo de la base de datos como si de una Access se tratase. Por lo que he leído al fin y al cabo una base de datos SQL Server Compact Edition no es más que un fichero sdf
    No, eso no funciona. A diferencia del mdb, que se puede compartir en red, el sdf queda bloqueado por la primera aplicación que lo abre, y otra aplicación no lo puede usar mientras la primera está en marcha.
    Lo que si me preocupa es no poder usar DLINQ, o tener que usarlo "a mano ", sin las ayudas de VS2008 para crear las entity set y temas como el DataBinding. SQL Server Express Edition: Tiene buena pinta, es gratis. El problema es que la instalación de la aplicación se complica, pues tengo que instalar primero el SQL Express y luego la aplicación. Además en comparación con SQL Compact los recursos utilizados son demasiados. SQL Express ocupa 200Mb y es un servicio, mientras que SQL Compact usa 2Mb y es un fichero, y se puede instalar a la vez que la aplicación. ¿Me equivoco en algo?
    Efectivamente, la versión Express es mucho más grande que la Compact. También es mucho más potente.
    Se puede instalar de forma automática si creas un proyecto de instalación o una instalación de ClickOnce y marcas el checkbox que lo añade como prerequisito.
    ¿Con SQL Express Edition no tendré problemas para crear las Entity classes arrastrando y soltando? Con SQL Server 2005 (que viene con Visual Studio 2008) no tengo ningún problema


    El que viene con el Visual Studio 2008 es precisamente la versión Express (además de la Compact, que también viene). No te debe dar ningún problema para usar el diseñador de linq-to-sql, ni tampoco con el Entity Framework, si prefieres usar éste.

     

     

    viernes, 5 de junio de 2009 11:36
  •  
    GUAU !!!! Me has resuelto todas mis dudas en una sola respuesta, claro y conciso.

    Con respecto a
    No, eso no funciona. A diferencia del mdb , que se puede compartir en red, el sdf queda bloqueado por la primera aplicación que lo abre, y otra aplicación no lo puede usar mientras la primera está en marcha.

    Supongo que quieres decir que no pueden acceder los dos puestos al fichero sdf a la vez, pero si cierro el programa en un puesto, el otro si podrá acceder al fichero sdf, ¿no?

    Me tranquiliza muchísimo pensar que se puede instalar como un prerequisito SQL Express.

    Ok, SQL Express es la versión que viene con VS2008, pero ¿cómo lo se? Cuando añado una conexión nueva en el Explorador de servidores, entre los proveedores me pone Microsoft SQL Server ¿cómo se que es la versión Express?

    Muchas gracias, finalmente creo que me decido por la Express.
    viernes, 5 de junio de 2009 12:13
  • Con respecto a
    No, eso no funciona. A diferencia del mdb , que se puede compartir en red, el sdf queda bloqueado por la primera aplicación que lo abre, y otra aplicación no lo puede usar mientras la primera está en marcha.

    Supongo que quieres decir que no pueden acceder los dos puestos al fichero sdf a la vez, pero si cierro el programa en un puesto, el otro si podrá acceder al fichero sdf, ¿no?
    Sí, con tal de que el acceso no sea simultáneo, no debería haber problema en que dos aplicaciones distintas usen el mismo sdf. 
    Ok, SQL Express es la versión que viene con VS2008, pero ¿cómo lo se? Cuando añado una conexión nueva en el Explorador de servidores, entre los proveedores me pone Microsoft SQL Server ¿cómo se que es la versión Express?
    No, lo que te sale al añadir la conexión es el CLIENTE de Sql Server. El cliente es el mismo con independencia de la versión de Sql Server que se ejecute en el servidor. Para saber la versión del servidor puedes enviarle un SELECT @@VERSION y examinar el texto que te devuelve.
    viernes, 5 de junio de 2009 14:33
  • Ok.

    Se me ocurre desarrollar la aplicación con la base de datos SQL Server Express,  para así poder usar el Object Relational Designer, y una vez creadas las Entity classes y el Data context, simplemente cambiar la cadena de conexión del DataContext. ¿Funcionaría?

    Si decido usar SQL Comact Edition y crear las Entity Classes a mano, ¿hay algún problema? ¿puedo usar DLINQ con SQL Compact Edition?

    Y una última duda, ¿qué hay de Microsoft SQL Database File ? ¿Qué es exactamente? Tiene pinta de ser una base de datos SQL Server en un fichero (sin servicio y sin SQL Server instalado)

    Muchas gracias de nuevo
    viernes, 5 de junio de 2009 15:03
  • No, no funcionará bien. La gracia del LINQ-to-SQL es que traduce las consultas escritas en el código fuente en sentencias Transact-SQL para el servidor. Sin embargo, no existe un cliente similar que haga una traducción análoga al dialecto reducido de SQL que usa la versión Compact. Así que si quieres usar LINQ con la Compact, el único remedio sería leer primero los datos a memoria y luego usar LINQ-to-Objects, o bien LINQ-to-ADO.NET si te traes los datos a un DataTable. En cualquiera de estos casos estarías realizando búsquedas secuenciales en memoria, prescindiendo del motor relacional.

    Aparte de eso, la idea de generar entidades con el diseñador, y luego cambiar la cadena de conexión, tampoco funcionará al 100%. Las entidades las puedes crear, y luego usarlas para contener los datos en memoria. Pero los mecanismos que leen y graban esas entidades, que están implementados dentro del DataContext, no te servirán (aunque cambies la cadena de conexión), ya que el DataContext depende del cliente Sql (que es distinto del de la versión Compact) y genera Transact-SQL que no siempre es compatible con la Compact.

    viernes, 5 de junio de 2009 15:14
  • Nuevamente una respuesta perfecta. Muchas gracias.

    Definitivamente usaré SQL Server Express, básicamente para poder utilizar el O/R Designer.

    Ya sólo me queda una duda. Es sobre el Entity Framework, que no tengo muy claro lo que es. Mi formación en .NET es básicamente la que da el libro de John Sharp "Microsoft Visual C# 2008 Step by Step " y en este no se comenta nada del Entity Framework. Te enseña primero a crear entity classes manualmente y luego te dice que las puedes crear automáticamente con el O/R Designer sobre una clase LINQ to SQL . El caso es que en un foro hace poco me comentaron que dejase de usar LINQ to SQL y que me pasase al Entity Framework. Mi duda es ¿lo que yo estoy usando no es el Entity Framework ?

    Ya se que no me vas a explicar el Entity Framework en una respuesta, tan sólo quiero saber si el que me lo dijo tiene razón y lo que yo estoy usando, LINQ to SQL + O/R Designer, tiende a ser sustituido por otra cosa llamada Entity Framework .

    Este es el mensaje original:
    Sólo a título informativo te comento que en un comunicado Microsoft advirtió que si bien Linq2Sql seguirá siendo soportado, Entity Framework será la plataforma recomendada para acceso a datos.


    Gracias
    martes, 9 de junio de 2009 10:16
  • Mi formación en .NET es básicamente la que da el libro de John Sharp "Microsoft Visual C# 2008 Step by Step " y en este no se comenta nada del Entity Framework.
    Entity Framework salió depués del Visual Studio 2008. Concretamente, se te añade al VS 2008 cuando instalas el Service Pack 1. Probablemente esa sea la razón de que no se mencione nada sobre EF en un libro escrito sobre el VS2008 original.
    Te enseña primero a crear entity classes manualmente y luego te dice que las puedes crear automáticamente con el O/R Designer sobre una clase LINQ to SQL . El caso es que en un foro hace poco me comentaron que dejase de usar LINQ to SQL y que me pasase al Entity Framework. Mi duda es ¿lo que yo estoy usando no es el Entity Framework ?
    No, son dos tecnologías separadas. LINQ-to-SQL utiliza un diseñador que, dentro de tu solución, maneja ficheros que acaban en .dbml ("Database Model"), mientras que EF diseña ficheros .edmx (Entity Data Model eXtension). Desde un punto de vista gráfico son similares, ya que en ambos arrastras tablas desde el Explorador de Servidores y las relacionas de forma análoga, pero los mecanismos de funcionamiento que hay por detrás son bastante distintos.
    Ya se que no me vas a explicar el Entity Framework en una respuesta, tan sólo quiero saber si el que me lo dijo tiene razón y lo que yo estoy usando, LINQ to SQL + O/R Designer, tiende a ser sustituido por otra cosa llamada Entity Framework .
    Sí, efectivamente, aunque Microsoft declara que Linq-to-sql no va a desaparecer, también indica que la evolución futura va a ir dirigida hacia Entity Framework, y que esta es la vía recomendada para desarrollos futuros. Sin embargo, conviene advertir que la "curva de aprendizaje" de Entity Framework es todavía más empinada que la de LINQ-to-SQL.
    martes, 9 de junio de 2009 14:29
  • Ok, me he visto una presentación del Entity Framework en msevents y lo tengo bastante mas claro. En cualquier caso parece que Entity Framework es "demasiado nuevo".  Seguiré desarrollando con LINQ-to-SQL y cuando llegue el momento daré el salto al Entity Framework.

    La idea básica que he pillado es que los que programamos en lenguajes Orientados a Objetos no tendríamos que manejar para nada datos relacionales (tablas, vistas...), y ese es el fundamento del Entity Framework, desligarnos de los datos, siendo el quien se encargue de hacer los objetos persistentes en una base de datos.

    Lo dicho, que de momento sigo con LINQ to SQL y cuando Entity Framework esté más mascado ya veremos.

    Muchísimas gracias Alberto.
    martes, 9 de junio de 2009 16:12
  • Tan solo decir que finalmente he encontrado la forma de usar LINQ to SQL con la versión SQL Server Compact Edition. La solución es usar sqlmetal, la herramienta de línea de comandos, para generar el .dbml

    La información la encontré aquí http://geeks.ms/blogs/lfranco/archive/2009/02/24/linq-to-sql-sql-compaq-tambi-233-n-existe.aspx
    lunes, 13 de julio de 2009 17:46