How can I ran x86 .net 3.5 Windows Forms app with .mdf database on the computer without SQL Server (for example, XP of common user).
I have found few samples of connection strings, but all of them are contains something like Data Source=.\SQLEXPRESS
Doubt, that user will be having SQLEXPRESS on his computer. I want something like work with Access db - so user could work without even knowing, what's server, only with local file
MSSQL I have chosen instead of Access, because in the future I can add publish DB on server, but not now.
Maybe, I should use SQLLite, but how in that case?
Thanks.
How can I ran x86 .net 3.5 Windows Forms app with .mdf database on the computer without SQL Server?
This question has very simple answer - you can't!
You must distribute and install some version/edition of SQL Server with your application, otherwise the .mdf file will be nothing more than waste of disk space. You can install SQL Server along with your app. For more information you can see Install SQL Server from the Command Prompt and Install SQL Server using a configuration file. If this is a simple app working locally on a single workstation, you may want to consider using SQL Server Express LocalDB.
Another option is to use different database engine, which has easier deployment and embedding - SQLite, Firebird Embedded, etc. Pick one that you like. Most of these solutions require only to distribute one DLL/assembly with your application. You will not get the full power of SQL Server, but for most apps, it isn't needed anyway.
Related
I am looking into using the new SQL Server Express LocalDB (I think it is code named "Denali") for a desktop application.
It is currently running with SQL Compact, but the user is wanting to share the database between multiple PCs on a network. Unfortunately this is not something that SQL Compact can do, so I am investigating other solutions.
The client requires the ability to send database files easily to other sites or to back them up to a flash disk, so I am avoiding going to SQL Express because there is quite a bit of "administrator" knowledge required to backup and restore.
So, my questions is, does the new SQL Express LocalDB support remote connections to the database over a network and/or through a shared network folder with the mdf file in it?
LocalDB does support supplying a path for an attached local DB in it's connect string (AttachDbFileName) hence the shared network folder option.
NOTE: This question pertains to "LocalDB" the new version of SQL Express 'Denali' and not to SQL Server Express 2008 or prior.
See article here announcing LocalDB's release: http://blogs.msdn.com/b/sqlexpress/archive/2011/07/12/introducing-localdb-a-better-sql-express.aspx
No, SQL Server Express LocalDB doesn't accept remote connections.
The idea with shared network folder might work, but only if you are able to make sure the LocalDB instance is shutdown before you try to copy the file. Also keep in mind that only one LocalDB instance can have any given database file open at the same time. and don't forget about the log files!
Additional security warning: unlike SQL Server Compact databases, SQL Server Express databases (including LocalDB ones) are not designed as secure data exchange format. For instance, they can contain malicious code in .NET assemblies embedded in them. So you should never open databases from untrusted source.
Maybe providing the customer with a simple tool that automates the backup process would be a better idea?
This isn't a fresh thread, but I would like to share my experience with SQL Server Express database LocalDB.
I have a WPF C# project using SQL database with LocalDb Engine. It is working fine no problem, I can use the database with the WPF app. I wanted this app to work on network with more PCs.
On the network another PC can use the database from my PC using UNC path in the connection string.
It seemed to me the remote connection is working. However when the remote PC is connected, I am not able to use the database with my local WPF app. If I run my app first the remote PC could not connect. So this tells me that the remote connection is working, but the multiple connection is not allowed.
OK, I didn't give up and I run the app from my PC twice and I saw it is working which tells me that the same SQL LocalDB engine can handle multiple connections locally only.
I hope this experience will help someone. Thanks.
In short, yes it can. Here is a tutorial on how to configure it.
Also, here is another post with a potential issue that might occur.
Both explain how to configure SQL Server Express to accept Remote Connections.
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'm writing an application in c# that uses SQL Server database for storage propose.
My question might be a bit silly, but yet I don't understand something..
I use a lot of application that use SQL Server for storage, but it looks like the DB is inside the application and installed in the installation process.
Does every time I use my SQL Server db in my application I need to install a SQL Server in my client's computer ?
Or can I somehow wrap my database in the installation ?
It looks a bit weird to me that a SQL Server must be installed in every computer I want to install the application on - although it uses a very simple database.
Maybe the solution is to use some other storage option ?
You can use a database like SQL Server CE or SQLite which doesn't require installing a server. It is just a single database file that is included with your program.
In teory you have to install only the client, but it is already installed in every Windows... You have just to config it. Run cliconfg on the command line. On 64 bit you have to choose which version (32 or 64 bit) to run
Usual practice for this kind of scenario is to provide user interface that would allow the client to enter server name and credentials with enough privileges.
I wouldn’t create an application that would automatically install SQL Server on client’s computer because that’s too intrusive.
Just provide a nice and clean user interface in the installation process and your clients will be able to do the rest.
Yes, there are options for SQL Server Compact Edition and other similar stuff but you’ll also have a ton of restrictions with these versions.
I have an application written in c# [WPF] which involves lot of communication with several databases, hence i used SQL server 2008. Now i need to move the code files along with the database files to another system(it doesn't have sql server installed). Once i run the applications exe , it gets struck as it is not able to retrieve data from .mdf file.
Is it possible to access sql server 2008 installed in my system through a network ?
It is pretty simple . I think you are using .mdf files as your database. Instead of it use .sdf as the database format which is mostly used in mobile development. There are lots of .mdf to .sdf converter available in the net.
You can have the second system access the SQL Server of the first system.
You need to modify the connection string so that it accesses a server on a remote machine, and make sure the proper authentication mechanism is used. If both machines are on the same Winodws domain, it's going to be fairly simple.
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).