I might be completely off on this, but is there a way to have a database project point to a remote server? My reason for asking is that we have a shared DEV Database for development use, and it seems like overkill for each developer to have a local instance of SQL Server as well. Is there a connection string that I can set or modify to point the remote server, or is the only way you can have a database project is to have a local instance on your machine. Please let me know if what I am asking does not make sense.
Thanks!
SQL Server Data Tools (which is what you're using for your database project) can work in two ways:
Connected Database mode.
Project oriented, offline database mode.
If you look at those articles. you will see that for development purposes, in both cases a localdb instance is needed. The local server is a limited SQL Server Express installation, which comes by default with Data Tools. So all you need to do is install Data Tools. If you already did, then you have localdb support.
More on this from MSDN:
Microsoft SQL Server 2012 provides a local on-demand server instance,
called SQL Server Express Local Database Runtime, which is activated
when you debug a SQL Server Database project. This local server
instance can be used as a sandbox for building, testing and debugging
your project. It is independent of any of your installed SQL Server
instances, and is not accessible outside SQL Server Data Tools (SSDT).
The workflow, for a central development database, would be:
Create the database project and distribute it to each developer.
Developers work "offline" and add/remove objects from the database.
Before submitting the changes to source control, each developer also syncs the local database changes with the central development database.
The rest of the team gets the changes from source control, so no manual sync needed. Only a new localdb publish would be required.
Of course, there are many other things to consider: local data (see here about replicating data to the real database), and some features not supported by localdb (like full text search).
I've tried this flow and works really well if you learn to control it. You always get a consistent central development database, without intermediary and unstable modifications.
You can change the "Debug" properties to point to a different server than the (localdb) instance. Most times you won't do this unless you're using some features that aren't supported in the (localdb). That would let you push the changes to your central server on each debug build. However, this could have a lot of unintended consequences if you're just playing around. The better option would be to leave the (localdb) debug instance alone and set up Publish Profiles for a real "Local" SQL Server install and for your shared Dev server. That way you can do all of your dev work offline and only push changes to the shared dev server when you're ready to do so.
I have a series of blog articles on SSDT at my blog that may be helpful: http://schottsql.blogspot.com. I'd also recommend looking at Jamie Thomson's blog at http://sqlblog.com - he has a lot of tips on DB and SQL Projects that could be helpful.
Related
I know this is kind of a stupid question but it gives me a lot of problems. Me and my partners in college projects have a lot of issues making the database mdf work when we send each other the visual studio projects. It gives us errors about the versions of sql server. Is the only solution to this to install same version of sql servers for the entire team or is there some other workaround?
Yes, you must be using the same version of SQL Server across all PC's.
You can never "go back" in time with a SQL Server database - once a .mdf file has been attached to a given version, it can never be attached to an older version anymore. And you cannot get around this by using the database compatibility level, either - the internal database file structures are just too different between versions, and no backwards "downgrade" path is provided.
One way to get around this would be to have a common, shared server somewhere that everyone can connect to and everyone can work with - making in unnecessary to send around "free-floating" .mdf files altogether... after all, it's SQL Server - a server-based system - not so much a file-based "database" system ....
Another way to go would be to stop sharing the binary .mdf file, but instead work with SQL scripts that you can exchange within your team, and that each team member can execute locally on their respective SQL Server instances - regardless of their local version
I suggest that instead of passing around mdf files, every person on your team creates the DB and then uses SQL scripts to create the objects. These scripts can be very easily created and exported from the SQL Server Management Studio.
This has the added bonus of being able to put the scripts under version control as part of the project.
I made such practice, with one way , by create separate pc running under windows server, only using as sql server to store all data record , then the data is called via "connectionStrings" of IP with server name of user policy, which is also secured by password and username , so this practice is used , to enabled two different programs to share that data , for example , that I made ( one web localhost app to create internal registration ),( the other web app using to access to mainpage via Login form).
I am creating a c# application which requires to use a database and i am also planning to create an installer for my application. I just want to ask which database would be best to use in my application and how do i install it on a user machine while installing my application through installer file.
I have thought of using MYSQL database but for that u need to have MYSQL installed.
Update
i want each user to have there own instance of database when they install the application
You do not have to ship a full database server with your application; only the redistributable runtime which your application would use to connect to the actual database server remotely. In the case of MySQL, you only need the assemblies.
Applications I wrote relied heavily on SQL Server. In order to simplify evaluations and the initial deployment, the installer would install SQL Server Express (installed as an application specific instance). This is an approach I'd recommend if your application is intended to a centralised database.
What is key to understand, especially with commercial application, is that the database engine you install may have to co-exist with existing versions of the respective database engine. That is why application specific instances was created for SQL Server Express.
The alternatives, which are embedded, are:
SQLite.net
SQL Server Compact Edition. The deployment process is well defined.
VistaDB
Embedded databases have some challenges when deployed as part of a server application. For many years, Microsoft refused to allow SQL Server Compact Edition to be used for ASP.NET applications. If the database is per user, per device, an embedded database may be perfect.
Also be aware that MySQL has license restrictions when shipped as part of commercial software (aka you're acting as an OEM, ISV or VAR).
Have a look at SQL Server Express Edition.
It's just a file which you can copy and a class library which allows to access it. And after you finished your installation you can just delete the files (or to keep them if you need them to uninstall the product).
may be u are a fresh.
MYSQL is ok ,but u are creating a C# application,i strongly advise you use mssql
because C# has a close relationship with mssql,develop more convenient.
My advice would be using SQL Azure.
But only if:
You don't need much storage (<1GB).
You don't save sensitive Data there.
Your users have an internet connection.
It's a cloud based Sql Server Database. And the Conneciton is very simple, basically you connect like to any other Database via the Connection String.
www.windowsazure.com
I need to create an application that does the following:
The application is going to be installed on multiple computers on the same network
There is going to be a computer that contains the database other computers will connect to that database. (So there is a server version of the software and a client version)
All the computers that have the application installed should be able to do CRUD (create, read,...) operations in the database.
Database will be small, that is it should be less than 1GB in size.
Problems that I have:
I don't know which database to use:
SQLite - From researching on the internet this seems like a great database. It is fast, very easy to deploy . The problem is that from researching I think it is not that good handling multiple connections. When I say multiple I mean 5 computers using the database simultaneously.
MySQL - I work with this database and I know it is great handling multiple connections. The problem with that database is that I don't know how I will be able to deploy that database. I am required to deploy a database when installing the software. I know that if I require the users to instal MySQL doing a separate installation that will work. Maybe there is a way of deploying MySQL when doploying a project in visual studio.
SQL Server Express - I believe this will be my best option. I have researched on the internet and I found out that it is possible to deploy a SQL Server Express database with a application. I believe it will be easy to figure out how to deploy such database with a project but it will be nice if someone can point me on the right direction on how to connect to that database remotely from a computer on the same network. The database will obviously be shared in the network in order to achieve this.
Microsoft Access Database - I never use this database. I know it can handle multiple connections. Maybe it is a good choice.
It will be nice if someone can point me on the right direction of how to be able to deploy a database when installing my application. Moreover how will I be able to connect to that database from a computer remotely on the same network. Since the database is small and it will just contain text I think that the best idea will be to keep the database on the internet but I cannot do that. The software is required to work without an internet connection.
EDIT
From looking at your answers it looks like I have to install SQL Server express or MySql on the server computer. The problem is that I am required to do one installation. Is there a way of deploying MySql or SQL Server Express when deploying my application. Perhaps I have to embed mysql in the application and make my application install it somehow. My boss want to be able to install the software without having a internet connection.
EDIT 2
I been thinking and this part will be very hard to implement. Do you guys have any ideas how QuickBooks implement their database? I guess I need something similar. When you install Quickbooks you perform just one installation. Quick-books handles pretty well simultaneous connections. Do they use their own database? Oracle? MySQL? I agree with all of you. It will be so easy to perform two installations. Also it will be cleaner. The software that I am creating is supposed to run on windows xp, and latter versions of windows.
If you want a dbms as your backend you are installing two things, It could look to the user like one thing, but I can tell you from bitter experience, that can be a lot of fun.
For instance to install 2005/ 2008 express, there are various prerequisites. Like a .net framework. Then there's patches and updates, then opening up the firewall(s), depends on set up. Different topology / os choices. Peer to peer, domain based, Active directory, Terminal Services, citrix.
So automagically installing without an internet connection, and using the installer for the db, is nigh on impossible, unless you have rigid control over the user environments.
Welcome to a world of hurt.
Oh did I mention permissions, shares, UAC, 32/64 bit (for sql server dmo and smo, maybe)
Do you want to block installs on "incompatible" environments.
Oh and what about upgrades. To the db, to your apps.
What if your client already has a server install and doesn't want to clutter up their kit with another...
and many many more.
And I bet you just can't wait to test all the potential combinations.
You haven't said what your target environments are going to be, so I can't say how many worms are in the tin, but its's very big time with plenty of room for lots of worms.
Ours is a long running legacy app, so we are pretty much snookered, I'd never willingly start with this design again though. Locally deployed web app would take a lot of the pain out of it.
Go back and scare the crap out of your boss.
I would recommend Sql Server Express installed on a server on your network.
Microsoft Access doesn't handle multiple simultaneous connections very well and is not very efficient when accessed from a remote machine.
You don't need to worry about deploying the database with your client application, you can install Sql Server Express directly on the server. (This only needs to be done once). You will need to configure Sql Server Express to accept remote connections after it is installed on the server.
SQLexpress supports multiple connections. So if you attach database on "server" computer you can than connect from clients same way as you would to local database.(provided those computers are in LAN or VPN).
Several articles on the Internet mention that SQLite is not that good handling multiple connections if all the connections are writing to the same database. I finally managed to deploy my application with SQL Server 2008 express. I also deployed my application with SQLite (downloaded the latest version for .NET framework 4). Since I plan to use this database just on a local network (LAN) I gave SQLite a try. I was impressed on how efficient SQLite was. I tested the Database by connecting with 4 computers symoltaniously and constantly writing data (inserts) to the database. No data was lost. When I did this with SQL express it was also very efficient and I could not tell a obvious difference. Maybe you get to see a real difference once there are 50 computers connected like on a web server for example.
Other nice things about SQLite are that it does not take time to deploy. Also there are no heavy services constantly running. I guess that SQLite is a better choice than SQL express. Moreover SQLexpress will only use 1 CPU and the database is limited to 2GB.
I am going to mist the Linq to SQL classes thought. They where very easy to implement with SQL Server Express. So in short I think that every database is good at something. And in this scenario I guess SQLite was a better option for me and for the users.
P.S.
I am interested in seeing how SQLite lattest version will hanle multiple connections compared to SQLexpress. I will try to test soon with more computers and each computer running multiple threads, each thread performing an insert in the database. maybe I,ll see a big difference with that scenario.
I am starting an application (c#, .net) that will interact with a Microsoft SQL database. I need the ability for multiple clients to access the data concurrently so I an going to use a service based database (.mdf). Is it possible to develop the application using a local database (.sdf) and then easily switch it over to a service based database when it comes time for deployment? Is that how this type of development it typically done?
You can control the data source by providing connection string to your database in .config file.
You can even create Debug and Release versions of your .config file with different connection strings. Debug can point to your local machine and Release to production.
Development shops vary, but it is pretty common to develop apps using SQL Express locally and then use a full installation of SQL Server for the production environment.
The only thing I would advise is make sure that the DB you chose for your dev environment supports the same features as what you expect in production. For example don't use SQL Express on your dev box when you expect to use Oracle in production.
If the database schema in both backends is exactly the same than the only thing you will need to do is change the connection string when you are ready to move to the service based database.
Be aware that the slightest change in the schema can (and probably will) cause problems.
You want to use SQL Compact Edition (as you said database file extension is .sdf), right? You can use MSSQL Express Edition instead, as it acts more like full MSSQL Server, and is still free and not so hard to install on developer's machine (I personally prefer this option). There are differences between the two (as explained here: http://blog.sqlauthority.com/2009/04/22/sql-server-difference-between-sql-server-compact-edition-ce-and-sql-server-express-edition/). If you don't want features like triggers/procedures/views in your database, you can still use CE, though.
If you have multiple clients then you should use SQL Server Express (.mdf file) - SQL Server Compact (.sdf file) is useful when you are building an application that is going to be deployed on client machines and will run standalone, e.g. windows forms application with a local database. SQL Server Compact is just an alternative for MS Access .mdb files or SQLite, the so called "embedded databases", while SQL Server Express is a real database server (albeit with some limitations to render it unsuitable for large commercial applications) and should be used in the cases where multiple clients use central database, e.g. web applications and smart client apps (the latter could also make use of a local embedded database though).
How can I make a program use a SQL Server database, and have that program work on whatever computer it's installed on.
If you've been following my string of questions today, you'd know that I'm making an open source and free Help Desk suite for small and medium businesses.
The client application.
The client application is a Windows Forms app. On installation and first launch on every client machine, it'll ask for the address of the main Help Desk server.
The server.
Here I plan to handle all incoming help requests, show them to the IT guys, and provide WCF services for the Client application to consume.
My dilemma lies in that, I know how to make the program run on my local machine; but I'm really stumped on how to make this work for everyone who wants to download and install the server bit on their Windows Server.
Would I have to make an SQL Script and have it run on the MS SQL server when a user wants to install the 'server' application?
Many thanks to all for your valuable time and effort to teach me. It's really really appreciated. :)
Edit:
To clarify, each business will have their server completely separate from me. I will have no access whatsoever to them nor will they be in any way connected to me. (I don't know why I should clarify this :P )
So, assuming the have ABSOLUTELY NO DATABASE SERVER installed; what can I do?
Ok, part of the answer, dealing with the SQL Server Database (and frankly SQL Server Express will take you a long way - 4Gb of data) and the server install elements.
Firstly make installation of the SQL an SEP, make it a pre-requisite possibly tweak your installers to test (challenging) but substantially point them at the links to SQL Server express and let them get on with it).
Secondly separate installers, as suggested, for your client and your server elements.
Finally, how to build the database - I'd suggest using code to create and maintain (update) the schema i.e. once you have a connection to a server you can run code that calls DDL that does what is necessary (something like suggested here: How to create "embedded" SQL 2008 database file if it doesn't exist?)
A question - are you intending all communications from the clients to go through you WCF service?
Your install application should:
Obtain a SQL Server name, a username (with apprpriate rights to create a database) and password.
Either run SQL scripts using the locally installed command line tool or from code using SMO (for instance), against the user supplied server with the supplied credentials.
BTW, Before you expend effort writing an open-source help desk, have you checked what is already available? Also, Open Source Helpdesk
It is not so straightforward to deploy a client/server solution with an automatic installation.
You probably would then be better off to deploy your server installation together with a database engine and a skeleton database already setup according to your wishes. This is to avoid tampering too much with the existing server - who knows whats on it.
Also you say you want to install WCF services, well this would probably mean installing them on a customer server, in theory this shouldn't be a problem however in reality it could be, depending on what is previously on the server.
Do you want a single SQL Server instance running on your machine, or one on each of your customers' servers? If it's the latter, you'll want to install a SQL Server instance - anything from the (free, but limited and not open-source) SQL Server Express to a more expensive SKU - on each server. You can include this step in your server installation package; MSI installs make it very easy to bundle a MSSQL install.
Then you'll need to drop a schema, and maybe data, on the instance. You could do this as a step in your installer, or as part of your application setup process. It possible that a SQL Server instance, or more than one, might already be installed on the server, and your post-install step should allow the user to specify which instance on which to install your pieces.
Then, include a database configuration piece in your client application. Ask the user - or take from a configuration file at client install time, to allow for unattended or unprompted client installs - server connection details, like server name and authentication information.
A word on authentication - since you appear to be building Windows-based tools, use Windows integrated (domain-managed) authentication if at all possible. Don't get in the business of storing logins, but instead rely on the existing domain to manage logins. A good strategy is to use active directory groups to manage access. Grant access to a particular group in SQL Server, and defer group membership to Active Directory itself. If you can't gain the access necessary to do this, then grant permissions to AD user accounts themselves. Avoid creating SQL Server logins, the use of which open the door to some possible security problems.
I understand what you are trying to do. If I were you, I'd do the following:
Provide 2 downloads - 1 for client and 1 for server.
Forget about MS SQL Server and perhaps go with MySQL, since it really is open source. You could probably get away with using MS SQL Server Express Edition, but if your data set gets gigantic large (which is common with help desk databases), you'd be stuck.
As other people pointed out, on very first run (or at setup time), I'd have the client app locate the server.