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.
Related
I was wondering which one is the best way to replicate some data of a database to another.
I have a database in one computer and this one receives some transactions. I need to send this data to another server (in the same local network) but with a modified value (I need to add 11 years to a Timestamp value).
So I was looking for some options for my case, I can develop a windows service to do this but I don't know if the sql server replication can do this for me or if there is another option like some kind of magical trigger that can do that.
I'm using SQL Server 2005 on Windows Server 2003 R2.
This link should help you:
Selecting the Appropriate Type of Replication
Quoted summary from link:
Microsoft SQL Server offers three types of replication. Each type of
replication is suited to different application requirements. Depending
on the needs of your application, you can use one or more types of
replication in a topology:
Snapshot replication
Transactional replication
Merge replication
I personally would replicate the database (transactional) and then use log shipping to update the replicated database (on your second server) with the latest data changes (from the primary server) then use a stored procedure running as a sql agent job to update the fields you need.
I personally am not a fan of triggers as you can end up having triggers activating other triggers and something that takes milliseconds to run can take seconds and if you have large volumes of data that can be painful (I manage a system that has exactly this issue - soon to be replaced thankfully)
hope this helps and if you have some follow up questions I'll be happy to help.
I'm developing an app that happens to have some records that need to be updated pretty often. I wanted to avoid deploying SQL Server on the client pc so I read a lot and thought a local .mdf file could be a solution (not so sure now if it's possible to avoid deploying SQL Server, after a few days I'm just realizing I could be miles away from right LOL).
Also, reading, I found there was a way to bind controls to data by visually moving objects from the Data Sources window, so I thought I was going to save a lot of time, but in the end I just got really confused because I couldn't get to actually write to the database file and information currently available seems to be pretty unspecific and works/doesn't for a lot of versions and flavors of VS (i.e. WPF, Windows Forms, vs 2008, vs 2010, and even older .NET framework versions), so I thought someone here in stackoverflow forums might have these things pretty clear.
So, I have some questions I believe will clear out my confusion (and anyone coming across this problem):
Can a .mdf file actually be used without a SQL Server installation?
VS is sometimes confusing, it offers to create a local database file without requiring a SQL Server install, I guess I take a lot of things for granted as I'm not an experienced .NET programmer.
If it's not possible. Is there any other way to avoid deploying SQL Server on the client, and is it a valid concern?
Maybe I shouldn't be worried about not deploying a SQL Server install on the client machine?
Can I get the fancy data bound controls to work with some similar kind of 'automagical' update call that writes changes directly to the database?
There seem to be two ways of managing the database using the app, and, of course, I would like to do it this way and just get those data bound controls to work, as the database is huge and there is not much to process in the way, just store.
Does the DataSet contain a temporal copy of the database?
I have a Database.mdf and a DataSet.xsd and, after searching for reference, I still don't know exactly what's up with these two guys.
No. When you create a new item in your project, the Server-based Database template creates an MDF file and requires a SQL Server Express instance to be installed on all clients.
The Local Database template creates an SDF file, which is a SQL Server CE database. Despite the name, SQL Server CE is a completely different product to SQL Server (Express). SQL Server CE doesn't use a server so you can either install it on the client or just deploy the required DLLs with your app.
Run the Data Source wizard and select your data source. The rest is done for you, as long as you select a supported data source. You can use SQL Server Instance, SQL Server Express File, SQL Server CE or Access out of the box. You can also support Oracle, MySQL and others with downloads from third-party providers.
The MDF is the actual data file, the same as big SQL Server uses to store data. The XSD is the XML schema definition for the DataSet, which is a class like any other. When you retrieve data from the database you use a table adapter, which is an instance of a custom class generated by the Data Source wizard. That table adapter wraps up the standard ADO.NET connection and data adapter objects that you would use yourself if you were not using the wizard. The Fill method of the table adapter populates a DataTable in a DataSet, which are also custom classes generated by the wizard that inherit the standard DataTable and DataSet classes. Once you've made the desired modifications to the data, you call Update on the table adapter to save the changes back to the database. If your controls are bound then populating the DataTable will automatically populate your controls and making modifications in your controls will automatically modify the data in the DataTable.
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
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 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.