We Keep Coding

How can you create a test database in Visual Studio?

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

How to set install time SQL queries

Alright so this might be a trivial question but I couldn't find anything regarding the title.
I've made this application for a store which uses a database named Store with some tables named Dealers, Orders, Sales and a view named DetailedRecord. What I want is, when this application is being installed on the client machine, the relevant SQL queries be run to make those tables and views on the client machine.
I need a step by step method to do this, any help would be appreciated.
Thanks

Once SQL Server is installed you can run a restore on the command line using SQLCMD.EXE. Here are some examples: http://www.howtogeek.com/50295/backup-your-sql-server-database-from-the-command-line/
So if you can call a command line from the installer, that's what you do.
I daresay just running object creation scripts might be simpler (and more modular) than restoring a backup. There are many editions of SQL Server, one of the ones at this link might be of use:
http://msdn.microsoft.com/en-us/evalcenter/hh230763.aspx

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 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.