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.
Related
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.
We have a project for school in which we have to create a web application. We have access to an online database, but the problem is that we have to connect through VPN before we can connect to it.
For this reason, we're looking for a possibility in which we have a local database (which would be in the project, I suppose?) that we can all use (the project is on a subversion server). But when we deploy the project on our deployment server, we want it to use the real database connection.
I think I've seen it before, but after searching for hours I couldn't find anything relevant.
Is this possible?
EDIT:
We use MVC5 with Entity Framework.
People typically do this in one of several ways depending on what you want to achieve.
Pull down the database as an mdf file and store it in your repository. You can then have a manual step during setup where you ask people to import it into their database (I recommend localdb for local development but sure, you can use sql server or something).
Advantages: Very simple to set up for the person arranging this.
Disadvantages: Manual step is difficult for beginners. If the database is large it will swell your repository. If one developer changes the database (for example by adding a column) then you have to let everyone know to blow away their copy and restore from backup. Also, there is no real explicit history of how your database changes and your test database is not integrated with whatever you have to do for deployment.
Pull down the database as an mdf file. Include this file in your project and set it's properties as Content/Copy if Newer. Then use it directly using a connection string to attachDb such as Server=(localdb)\v11.0;AttachDbFilename=.\MyDataFile.mdf;Database=dbname;.
Advantages: No manual step, everything just works
Disadvantages: Obviously you'd want to use relative paths for AttachDbFilename and I'm not 100% that this is supported. Also, same as above but instead of having to let everyone know when their db needs restoration it just restores behind the scenes. This can mean users suddenly see their data disappear with no notice. It can also fail sometimes due to things like a locked database file and everyone just has to get good at keeping an eye out for that.
Maintain a sql script that can recreate your database in localdb. Provide people with a powershell or batch script (also in source control) to run it easily. Optionally use a post-build script that determines if you need to recreate the database and runs it.
Advantages: Everything is very explicit. Reasonably small size in the repository (which should be able to store text efficiently). You can use the same script as part of deployment.
Disadvantages: More work to set up. Still no real way to deploy changes to existing databases.
Use Entity Framework Database first. I can't speak to what the process looks like exactly when doing this but I know that it is possible.
Advantages: I guess.
Disadvantages: Ewwww EF database first
Use Entity Framework Code First with Migrations. Use explicit migrations (not the silly auto-generate-my-entire-db cruft) and write a proper Seed method to populate your data.
Advantages: This is what professional developers do and is based on tested patterns used frequently by Rails, Django, and many other frameworks. It is very flexible and explicit and supports changing existing databases.
Disadvantages: Can be quite difficult to set up if you don't have experience and especially if you're unaware of the migrations pattern. There's some naming difficulties that make it kind of hard to google (database first EF vs code-first EF, explicit migrations vs auto-generate-the-db, several different Seed methods that depend on your initializer).
You can create a local database using Entity Framework, which saves the database file on the local filesystem, which you can push to your version control server to share with your colleagues. If you decide to deploy the database, you can generate an sql script that you can run on the production database. You can do so by connecting to the local database using SQL Management Studio. You will just need to modify the connection string of the published application after deployment.
You used to be able to use Sql Server Express but it has changed to LocalDB and can be installed and run locally.
http://blogs.msdn.com/b/sqlexpress/archive/2011/07/12/introducing-localdb-a-better-sql-express.aspx
https://msdn.microsoft.com/en-us/library/ms233763.aspx
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 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.
I have a C# application that's utilizes MYSQL. I'm at a beta release point and need an installation package that includes my application, along with MYSQL. So basically, I need to install MYSQL and perform a restore from within my .NET install package.
Any help would be greatly appreciated.
Step 1: You're doing it wrong
You're attempting to install the mysql server. This should be your first clue that something is wrong. Most server apps are designed to be installed on servers, not on clients. The notable point in this is that server apps like to assume that they 'own' the server. This is a giant no-no for client apps.
Step 2: Make a decision, now that we are properly informed
Now that we've established that we're doing it wrong, we need to choose what to do. We have 2 options:
Switch away from MySQL to a 'client' database such as SQLite or SQL Server Compact Edition.
Hack around the problems of installing the server app.
I personally would recommend switching to SQLite (or similar) as soon as possible. It's the "right thing" to do, and you won't have to be maintaining hacks for years to come.
Step 3: You'll want to hack MySQL anyway because it probably seems easier.
You have been warned. Here are some of the things you will need to be aware of, and mitigate:
MySQL wants to install into program files\mysql. If the user already has MySQL installed themselves. You'll break everything
You'll need to tell your version of MySQL to install into a custom folder. I'd recommend it as a subfolder of your application
MySQL wants to run as a service (and the service will likely be called 'mysql'). Again if the user already has mysql, you'll break everything.
You'll need to run your service under a different name
The MySQL server will likely want to write files to Program Files\etc.
You'll need to change it's configuration so it writes to %APPDATA% and so on
MySQL will assume it is always being run by the same user. If you have 2 users on the machine who want to use your program, you'll need to hack accordingly, by either running MySQL as a local service account (security flaws ahoy), or by installing a seperate mysql for each user.
So with all this in mind, I'd say your best bet is to set up an xcopyable mysql
I've post the answer on another question
We took a different approach on this. We make MySQL xcopy-able, by writting a wrapper to generate the configuration file before calling MySQL (to correctly setup the base path and so on). Then we have another service installed using the standard setup. This service will take care of starting MySQL and other required background program (in our case Apache) for us. Since the MySQL is deploy by us, we wanted to have full control over it.
So with this method, you could simply include the MySQL package along with your installation, and just worried about installing your own service.
If you're using, or can use, NSIS, you should read this: Silent MySQL Install
Regarding the restore, you might be able to script something up using one of MySQL's included utils or modify part of this old NSIS script
Good luck!
This question is very similar to another question. However, the answers don't really help.
You can run executables from a custom action in the .Net deployment project, that's what I'd recommend. (Look under the heading "Calling an executable as a custom action")
Hopefully everything can be taken care of by via the command line. If not, try a scripted installer like Wise or InstallShield, I think they have better support for stuff like this.
Hope that helps!
#Orion Edwards
Thanks a lot for the steps. I was having the SAME doubt. In fact, We just turned SQLite down because our standalone application needed some procedures and foreign key contraints.But now I feel SQLite is always a better choice for standalone desktop application if it is do be deployed on client machines.
For now,I have to stick to MySQL. So I'm using different kinds of scripts and mechanisms to handle different possible situations. Eg:
If the client machine has no mysql pre-installed, there is a script which completely installs the server and creates the database, users required for my application.
If mysql is pre-installed on client machine, I'm asking user for mysql's root username and password and setting up the database & users from within the apllication.
And thirdly, if for some reason client machine had mysql server earlier and then it was uninstalled, since mysql DOES keep track of previous root password even after uninstalling,I run mysql server's .msi, reset the password (manually carry out some steps), and finally create instance of database, all within a script (of course these steps are needed to be carried out by US, not the user as this is a very rare case.)
Is this approach OK? Or there is a better,appropriate way to do this?
In future I think i'll stick to SQLite! :-p
Have a look at using Visual Studio's package and deployment tool. It should automatically bring in the MySQL dependencies if you connect natively (MySQL .NET components) rather than an ODBC connection. In any case it allows you to add other software to an installation program that can be automatically unpacked if you need it. I have used it to deploy C# apps using the MySQL libraries that you download from MySQL website and for CoreLab's MySQL 3rd party libraries.