We Keep Coding

C# application using a Local database with stored procedures

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.

How to create a SQL Server database programmatically in C#

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 to evolve SQL Server database of MVC3 sites in the future and avoid data lost

I'm getting ready to develop a MVC 3 website with C#, Entity Framework and SQL Server.
This website is built for critical jobs and data lost is something absolutely not allowed ! In my knowledge I had no experience of evolving database, but I know this project should be able to evolve while using incremental development methodology. May I know is there any guideline to follow and how do I evolve it without any single error? In term of database initial design or anything. Just, 0 Data Lost is highest priority requirement.
I need answer for this 2 question and hope some experience could guide me in this issue
How to update database include table, column without affect other data in the same table
How to update remote database (for example C# window apps and database is not with me)
For the 1. question the database is located at my web server but question 2 the database is staying with user end.

The answer is: it is your duty to design upgrade process in the way your requirements are met. There is no auto magic which will do this for you.
The process usually involves creation of upgrade SQL script which will modify database structure and if needed it can also move data to temporary tables while structure of main tables are changed so that data are not lost. You can also maintain database version in some special table and check it before you run the update so that you ensure that update script is run on expected old version.
There are tools like RedGate SQL Compare and Visual Studio Database tools (only Premium and Ultimate version) which are able to take old database, a new database and create difference script for you so that old database schema can be upgraded to a newer one. This works for most scenarios but you must always very carefully test result in your testing environment. It is best to test in on backup of your production database if possible.
How to avoid data loss if anything goes wrong? There is only one very simple way BACKUP THE DATABASE before you do any changes and restore the old database if anything goes wrong. Backup can be even scripted with SQL. Without successful backup never touch your production database.
How to upgrade client side database? You will use the same process but you will wrap it all in some installation package (.msi) for example created with WiX.

I need to create the same database on many server instances

SQL Server 2008, Visual Studio 08 and C#
The task is to create the same database on multiple servers. If it were only two or three tables I would have done it manually but there are more than 50 tables in the database..
So I thought why not create a backup and restore the backup file wherever needed
error
the file is in use! ( although the backup is not in use, the error is saying that the actual db is in use! YES IT IS, i cannot close the server each time i want to restore the backup on other servers!)
So what should I do, please give your ideas
And also note
Whatever you say should be achievable using SMO objects also
thank you

[REVISED - I need to learn to read better]
I'm not certain about SMO Objects, but given that SMO can work like other SQL Server functionality, what we do for our project is to use a Database Project that deploys to our servers automatically. This probably requires Database Edition (VS 2008) or higher...premium in 2010. If you have that, it's definitely a nice option to create a DB project. Then, you just set it up to do a schema compare (and you might be able to do a data compare as well if you need that...?) during deployment. Auto-deployment is harder to setup initially, but once it's setup, you're good to go with single click deployments...we use TFS to deploy right now, but I hear good things about TeamCity:
http://www.jetbrains.com/teamcity/
Kevin

Use
usp_killDBConnections #DBName=''DbName''
before you run restore operation. The command will kill all DB connection before Restore, which is important during restoration.

Prior to running the restore, you can run the stored procedure 'sp_who2' and it will list the current connections to the database. If you are going to overwrite the DB anyways, for each of those connections you can issue a 'kill ' to forceably close the connections.
I also recall there being some "close all existing connections" option when using the restore GUI in Sql management studio.

How to install and setup a database with .NET?

I am currently working on a project that include the use of SQLServer. I would like to know what strategy I should use when I install the software to build the database? I need to set up the tables, the stored procedures and the users.
Does my software need to make a check on start up to see if the database exist and then if it doesn't, create it up?
Is there any way that I could automate this when I install SQLServer?
Thank you.
EDIT
Ok right now I have plenty of nice solution, but I am really looking for a solution (free or open source would be awesome) that would allow me to deploy a new application that needs SQLServer to be freshly installed and setuped to the needs of the software.

RedGate software offers SQL Packager which gives you option to produce a script/.exe to deploy whole db including everything (stored procedures, tables etc) from one single .exe. If you can afford it and want to have easy way to do it (without having to do it yourself) it's the way to go ;-)
Easy roll-out of database updates across your client base
Script and compress your schema and data accurately and quickly
Package any pre-existing SQL script as a .exe, or launch as a C# project
Simplify deployments and updates for SQL Server 2000, 2005 and 2008

You could use migration framework like Migrator.Net, then you could run the migrations every time your application starts. The good thing about this approach is that you can update your database when you release a new version of your software.
Go take a look at their Getting started page. This might clear up the concept.
I have succesfully used this approach to solve the problem you are confronted with.

You do all of that with the SQL scripts. And then your installation program runs them against the customer's SQL Server.

You can write a T-SQL script that only creates objects when they do not exist. For a database:
if db_id('dbname') is null
create database dbname
For a stored procedure (see MSDN for a list of object types):
if object_id('spname', 'P') is null
exec ('create procedure dbo.spname as select 1')
go
alter procedure dbo.spname
as
<procedure definition>
The good thing about such scripts is that running them multiple times doesn't create a problem- all the objects will already exist, so the script won't do anything a second time.

Setting up the server is pretty straight forward if you're using MS SQL Server. As for creating the database and tables, you generally only do this once. The whole point of a database is that the data is persistent, so if there's a chance that the database won't exist you've either got a) major stability problems, or b) no need for an actual database.
Designing the database, tables, and procedures is an entire component of the software development process. When I do this I usually keep all of my creation scripts in source control. After creation you will write the program in such a way that it assumes the database already exists - checking for connectivity is one thing, but the program should never think that there is no database at all.

you can make a script from all of objects that exist in your db. after that you can run this script from your code.
when you create your db script with script wizard in sql server, in "choose script options" section, set "Include If Not Exist" to yes. with this work done only if db not exists.