I'm using the Entity Framework in a small command line application.
Now I want to deploy this program - and I want it to create a small local file based sql database besides the program, if it doesn't exist (first start).
What is the best practice for such a simple project? SQLLite, SQL Server Compact Edition? I don't want to create the database manually from within Visual Studio - since the later users of the program wouldn't be able to do the same. Also there should be not setup or "manually setup of a database" for the user later.
Or do I have to deploy a simple, empty database file with the application itself? But how specify I this database in the connection string during development?
Thanks
Konrad
It firgured out, that SQL Server Compact Edition was the best solution.
Related
I have a database project in my solution and the requirement is simple (not so sure about the implementation).
Is there a way to deploy the database project programatically?
PS: I don't mean attach an MDF file. I mean deploy the database to a SQL Server instance.
You can add the script for create the database as an "Embedded Resource" then execute it when needed with the standard ExecuteNonQuery(...). But you probably need to upgrade it in the future so the idea is, a part the first drop, have some table somewhere keeping the schema version, then have multiple embedded resource contatining script to jump to one version to the next one. When the service start check the version against the expected one, if not the same launch the needed script(s) to reach the current version.
You can use plain sql commands to achieve this.
http://msdn.microsoft.com/en-us/library/49b92ztk(v=vs.80).aspx
http://www.codeproject.com/Articles/16231/Deploy-your-Application-and-Database
Best regards
Create the database SQL however you like and include it in your project. Then simply execute the SQL script against the server.
I use this when I include SQLite databases in my project.
I am trying to develop a simple C# application which use a database. I am currently using MS Server 2008, but I found a portability issue since running the application on different computers would require MS Server to be installed. Also, my database makes use of stored procedures.
What other database types I can use in order to overcome this problem (n.b. it must use stored procedures)?
If I am to use MS Server 2008, assuming it is installed on every pc, how can I copy my .mdf file in order to be accessible? (i.e. install it on application load ?)
UPDATE
From this website, I found the following connection string :
Attach a database file on connect to a local SQL Server Express instance ...
Server=.\SQLExpress;AttachDbFilename=c:\asd\qwe\mydbfile.mdf;Database=dbname; Trusted_Connection=Yes;
I presume that this will copy the .mdf file from my folder.
Hence, I am using the following connection string but to no success ...
Server=.\SQLExpress;AttachDbFilename=...... database path.... ;Database=TrieDB.mdf; Trusted_Connection=Yes;
Directory lookup for the file "... database path... " failed with the operating system error 5(Access is denied.).
Cannot attach the file '... database path...' as database 'TrieDB.mdf'
Most "certified" database engines requires you to actually install the engine.
Most "certified" database engines enable the use of stored procedures.
In order to have the .mdf file on more machines you can simply copy it and afterwards use the sql management studio to attach the file to the engine, but that is not an ideal solution if you planning to distribute your application in many places, the ideal solution will be to create an installation package and fix that it is automaticlly being done from the installation and undone when you uninstall.
imho: You insist on stored procedure with a de-centeralized solution - do notice that this is a rather rare tactic - it has the smell of a wrong path..
But I can't be sure unless you provide some more information.
There are really two general designs to do something like what you're describing. Either have a centralized database that all copies of the application (and/or multiple applications) access, or create an installation package complete with the database (which is generally only accessed by a single application).
Personally, if you don't want to, or can't, use a centralized database solution, I would suggest changing your philosophy about stored procedures and looking into SQL Server Compact. I found this article discussing the reasons why SQL Server Compact doesn't have sprocs, which I think will be useful to you, even if you decide you really need them.
That said, if you need to install a database with your app, you can create a setup package within Visual Studio, of you could also look into using WiX.
You can detach the database, copy over and attach the mdf file on the destination database.
I'm wondering what's the best way to create an database application using VS C# 2010 Express Edition and I have two questions:
What should I choose Microsoft SQL Server 2008 or SQL Server Compact
3.5? 2008 seems to be more complicated to install on user's desktop. If I am right, to use Compact you only need to install this
server and after that application is just able to use database
file.
What should I include into my package, .dll file will be enough or do I need whole for example Sql Server Compact installer?
You may use LocalDB from new SQL Server 2012 Express. I thing it's ideal for desktop apps. More info at MSDN and SQL Server Express WebLog.
Just to add, might help...
I'd suggest to use NuGet to download / install EntityFramework (type it in there and you'll get a list).
You have two versions, one regular flavor and one for compact edition.
http://nuget.org/packages/EntityFramework/4.3.1
http://nuget.org/packages/entityframework.sqlservercompact
And with that you'll get a basic 'framework' for dealing with databases as well (you'd need just to install the SqlCE (suggest 4 as is newest)) - NuGet installs the dll-s needed.
You can use 'model first' approach with EF (entity framework) to create Db first,
or even better use 'code first' approach - to create Db automatically from your code, classes.
That'd take care of creating new Db etc.
I think that's the easiest way to 'start up' with a new Db. And CE as well.
CE (compact) is a good choice - but watch, it has certain limitations comparing to the standard server SQL (express or standard etc.). E.g. you cannot use I think xml fields, and some other things, stored procedures, views etc. (If I'm correct and remember from before).
Also depends on what you want to make and where to deploy. Desktop doesn't mean that CE is best solution (depends on many details).
hope this helps
MSDN has some documentation on how to deploy SQL Server Compact with your app. It's indeed possible to both install it separately, or bundle it with your application, which is probably what you want.
I want to create a program, that will use SQL Server 2008 database. During the first start, I would like to open a window, which let the user create a database. It will be simply, textboxes with name and ip of the database computer to set and button "Go".
Program will be in WPF .NET4. And database will be in local network.
Could you suggest me a good solution? Is it a good programming practice, to do that? Or maybe I should just attached a sql script?
I do some research, I found that article: http://www.codeproject.com/KB/tips/CreateSQLDV.aspx
But, first issue, in SQL Server 2008, there is no Microsoft.SqlServer.SmoEnum.dll. So, when I do similar "data create" window, but for SQL Server 2008 (using maybe different dlls) - It will not work for SQL Server 2005. And maybe will not work with other versions of SQL Server 2008 to? I don't know.. Example from codeproject looks good, but I'm not sure.
I would like to do a flexible program.
I would recommend not to actually programmatically create the database. As you mentioned - with different versions of SMO, this becomes a bit of a nightmare.
My approach would be this:
with your installation, ship a "default" empty database that has your base structure (all your tables and everything) and possibly also some basic lookup data in certain tables
when the user indicates he doesn't have an existing database for your application, copy the MDF/LDF/and possibly NDF files to the SQL Server data location
attach those database files programmatically to the SQL Server instance
That seems a nice cleaner and more flexible approach.
I would avoid SMO.
It depends a LOT on your audience and the control you have over the expected environment, but attaching pre-made databases, while a convenient option, can sometimes have issues - to start with it's a binary under source control, so you don't get diffs for free in your source control system. In addition, you're attaching a database with certain options and things which might not be appropriate for the specific target environment - SQL Server 2005, SQL Server 2008, SQL Server 2008 R2? Other than all that, it's a valid approach similar to the way one might deploy Access applications in the past.
In a less controlled environment, I would go with either generating a SQL script containing all the DDL (and DML for lookup tables) or providing a script, offering to run it automatically and also giving them the option of running it themselves with their own tools (if they have a DBA).
Now your script (or at least the template for the script or the code that generates the script) is under source control and can satisfy a DBA who wants to inspect it.
The database creation may not need to be a part of your code per se. Especially, if you only need to create the database once. I suggest an approach on which you create an installer either by using Windows Installer or Inno Setup (I prefer Inno Setup). With an installer you can prompt the user for their SQL server name and the login credentials for their administrative user. Then you can use those to run a SQL script containing your CREATE DATABASE and CREATE TABLE statements, etcetera. Hope this helps.
How can I publish the application database along with it?
I'm using Visual Studio 2008 with C# language.
The database has the log-in information needed in order to go in the MdiParent and do tasks there. The same database is where employee records would also be saved...
I'm currently developing an employee information system.
The easiest option it to use a file based database and distribute it with your application, unless you need the data to be shared between all users of the applications as it changes.
SqlLite and SQL Server CE are both file based.
What is your db engine? For MySQL, I use the utility mysqldump. You then can use the source command in a scripted installer to deploy your db from the dump file.
With SQLSERVER, I use the Import/Export tool that comes with SQLSERVER to script out the db with any data that I want to have deployed with the database. I then run the script on the db in my installer.
You have several options. The question is, what are you using for an installer? NSIS, Visual Studio Setup Projects? etc... How you answer that will determine the best approach for how to deploy your database.
You can also do as #oded recommends though I have never done this except for with basic ASP.NET sites and the sqlexpress db that come with the VS project. Usually, I find that whether or not it is a good idea to use the file just depends on your complexity.