I ran into a stupid problem.
I started developing a Windows Forms application in C# that must be stand-alone (work with absolutely no installation) and needs a database. Being genius that I am I didn't read too much into it and used SQL Server Express .MDF database.
Now it works perfectly, with Linq and all it's perks (data context, designer and so on) but what I didn't know is that client machine will need SQL Server installed to work with database. My program will be potentially deployed to 200-250 PCs and installing SQL Server on all of those PCs is not an option.
Is there any way to use a SQL Server CE database instead of .MDF? Or will I have to rewrite half the program?
First, read about SQL LocalDB.
It still requires installation and requires administrator rights for installation. However it supports silent installs, installer size is only 33MB, and it supports the majority of the features of the full-blown SQL.
If you cannot afford any installs at all, then yes, SQL CE might be an option for you. Whether you’ll need to rewrite half the program depends on how exactly you use your database. If you rely on stored procedures, views, raw SQL, other advanced features then yes, you might need to rewrite half of your program. If you only use linq2sql with simple queries, then you might be fine and only need to rewrite the DB initialization code.
Remember the last visual studio that supports SQL CE tools is 2012.
If you can’t install anything at all, and you will be rewriting half of your app — remember there’re many embedded databases now days.
You could instead prefer SQLite: it’s cross platform, extremely popular, SQL language.
Or ESENT: there’s no SQL but it has tables/schema/indices/transactions, part of Windows wince win2k, the performance is really good, 10-100k requests/seconds is normal.
Related
I am looking for a solution in which several applications on the same machine access one and the same database. Generally the operations are just reads thus I am not interested in having to provide concurrent write access as well.
I checked into SQL Server Express, SQL Server LocalDb, SQL CE, SQLite, MySQL and am not convinced which one is the best solution. I read that SQL CE allows concurrent read access but SQL Server LocalDb does not, which I find very odd given LocalDb is hyped by MS as a version that is very similar in functionality to the SQL Server family and which is supposed to make it easy to later on scale out.
I like to manage 5-10 tables each of which holds less than 5000 rows, so really lightweight content.
I am looking for a solution that meets the following requirements:
Concurrent read access by several applications on the same machine
Should be somewhat lightweight. I intend to move all applications within a solution to a different machine later and do not want to have to install a 200mb full blown SQL Server Ex#ress version if possible.
Should play well with VS2012 express (sqlite and mysql are highly unsupported in that regards, either not supporting EF5 or they do not show up in the server explorer.
Should be an SQL solution in order to manually update database tables within a management console such as Workbench or Management Studio or other third party app.
Should work somewhat with EF or other ORM solution. I want to be able to create an entity class and create a database from that or update tables using class objects. Also I want to populate class object collections from table rows without having to go through SQL code.
I target C# in .Net 4.5 and I guess it boils down to the question whether SQL CE is up to the task to allow concurrent reads and how I can load CE data tables and edit and visualize the content in some sort of management console. Also does SQL CE play well with EF5? Any better suggestions?
Since you're asking for an opinion, SQLite is my answer.
We are aware of no other embedded SQL database engine that supports as
much concurrency as SQLite. SQLite allows multiple processes to have
the database file open at once, and for multiple processes to read the
database at once. When any process wants to write, it must lock the
entire database file for the duration of its update. But that normally
only takes a few milliseconds. Other processes just wait on the writer
to finish then continue about their business. Other embedded SQL
database engines typically only allow a single process to connect to
the database at once.
Entity Framework on SQLite
System.Data.SQLite
Setups for 32-bit Windows (.NET Framework 4.5)
This setup package is capable of installing the design-time components for Visual Studio 2012.
SQL CE Works with EF5 and VS 2012 Express, is very lightweight, supports multiple readers on the same machine, and can be managed in VS Pro+ combined with the SQL Server Compact Toolbox add-in (or standalone) (I am the author)
So far I have been using SQL Server Express on my desktop application even though usually the server is only used by that single application, by the single user, on the same single machine. This always seemed a bit silly to me since the full-on server is rather heavy.
Then I found out that there is something called SQL Server Compact. Thing is, my application is already rather large. So my question is that if I wanted to change to SQL Server Compact, what kind of changes to my code are we talking about (using C#)?
Mainly I'm wondering if I can access the Compact -version in the same manner as I can access the Express one, which is using ADO.NET and pointing it towards localhost\sqlexpress. So would it be possible to create another instance with the Compact and just point my application to that, or is it used in a completely different manner?
For a standalone desktop product it is certainly a lightweight option to consider over SQL Express.
However there are differences between the two to be aware of other than just connection strings. For example SQL CE does not support stored procedures, user-defined functions, or triggers. Additionally it does not support the full range of datatypes that Express supports. On a technical level it also runs in process with your application.
Another consideration is that while SSMS will work with SQL CE databases, it's not as fully featured as it is with SQL Express. There are however a whole raft of good tools out there for filling these gaps. Take a look at Erik Jensen's blog for a good overview.
Everything SQL Server Compact
Also check out his tool for migrating SQL Express databases to SQL Compact:
How to Migrate/Downsize a SQL Server database to SQL Server Compact 4.0 (and 3.5)
Finally take a look at this SO question for more background between the two products:
What are the limitations to SQL Server Compact? (Or - how does one choose a database to use on MS platforms?)
I worked recently with it, by the way the things I know about using them is that SQL Express has a server to connect to, and, Compact is a sdf file, so the first thing you will have to change is the connection string to it.
After this change, there are no more heavy changes to be done, I remember, compact has almost all the instructions of the express server available, so, it could not be much problem.
Take a look at Microsoft documentation for more information, or at Wikipedia.
See you.
I would vote against SQL CE:
It has no views, which might be an issue when migrating.
We recently did something similar which you described and had tremendous performance impacts when switching from SQL Server Express to SQL Server Compact Edition.
My recommendations would be:
Use SQLite (which we did for the project I mentioned - it was much more performant than SQL CE in our case) -or-
Use VistaDB (which I did in other projects; not as performant as SQL Server Express, but still sufficient)
Both databases can be XCOPY deployed, just like SQL Server Compact Edition.
SQL CE has the same size limitation as Express, so you should be good.
As far as moving between the two, I found this for moving between express databases and compact 3.5 databases. Then I think you'll only have to change your connection strings (instead of pointing at a host/instance, you point at the converted file). There are different features between the two, though, so you might have to change your schema in the original database for the conversion to go smoothly.
Ok before I explain... I know Access should basically not be used anymore.
My application now uses access for its portability.. its an internal application and makes private/internal database storage a snap.
Problem is, it uses JET 4.0 which is not supported in 64 bit operating systems and is frankly not very well implemented anymore.
I am developing using C# .NET visual studio 2008. I am looking for a way to do this with some other database type that would not require me to install anything else on a users computer. I looked into sqlite but there's no easy way to implement it in visual studio
An Ideas?
You can use SQL Server Compact 3.5 (the embedded version of SQL Server 2008).
I recommend System.Data.Sqlite (http://sqlite.phxsoftware.com/), a managed, open-source ADO.Net wrapper around the open-source Sqlite database. No installation required - you just include the single DLL in your solution. It boasts a small footprint, encryption, and good performance.
SQL Server Express edition should come with Visual Studio. It is an option at installation time, IIRC.
Access has a couple of key characteristics:
- Single-user
- Requires installation
For alternatives this gives you (at least):
SQL Compact (doesn't require installation, single-user)
SQLite (doesn't require installation, single-user--although multi-user is supported)
SQL Express (multi-user, requires install)
SQL CE is a good option as already mentioned. You could also consider xml if the data is not private and you don't have concurrent users (which is very likely if you are using Access). Xpath provides a lot of the features you would normally need from database queries and storage. You also wouldn't need to install anything.
Did you try with H2?
The main features of H2 are:
Very fast, open source, JDBC API
Embedded and server modes; in-memory databases
Browser based Console application
Small footprint: around 1 MB jar file size
Check out about implementation:
http://www.google.ba/search?sourceid=chrome&ie=UTF-8&q=C%23+h2+database
This is one reason why people continue to use Access. Of course you want an easy solution that doesn't require any installs on the client side.
We've all assumed so far your users are disconnected from your SQL Server. If they can connect, you're home free. It's less of a problem if you need to support read-only disconnected use, more of a problem if you need to pull updated data from disconnected users.
Can you tell us more about what you need?
Firebird can be a very good alternative to Access and have very good dot net driver
Here is a comparison between Firebird Embedded and SQL Server Compact Edition
How about XML? Easy to use, and it works on any platform. Not the easies to implement if you're unfamiliar with it, but it's pretty rad once you learn how it works.
How can I release a winform application to a user that takes advantage of a local sql database. I would assume that I need to install the database during some kind of setup phase, but is this kind of thing possible? Is there a free version of tsql that can be used in this way? Mysql?
TSQL is a language specification, not an actual database.
If you're talking about MS SQL Server, it is possible to bundle and install an instance of SQL Server Express, if you want to distribute a database with your app. There's some documentation on it over on MSDN, specifically, Embedding SQL Server Express into Custom Applications.
SQL Server Compact Edition is suitable for this. It has some limitations in that it does not support the full set of functionality that SQL Server supports (ie. stored procedures is one example), but it does mean that you don't need an installation of SQL Server to use it. If you are only using the database as a "bit bucket" to store and retrieve data, then it should suffice.
Another alternative is to use SQL Server Express Edition. This does require installing a proper SQL Server instance, but basically gives you a cut down version of the full SQL Server, enabling you to use more of its features.
Both of these are free.
You might also want to check out VistaDB. It is syntactically compatible (although not perfectly) with sql server. All managed code. But it is not free.
SQL Server Compact Edition does not support stored procs, fyi. But is a single file deployment plus your data file.
SQLite is extremely fast and lightweight. Deployment is single file plus data file. But it has some syntactic limitations and has limitations to its dotnet integration (although I am pretty sure there IS a ado.net provider for it.)
I support an application built on sql express edition and it is a PAIN. It has a lot of install failures. (Probably about 10k installs over the last 3 years.) But if you need to power, hot backup, full sp and function support, connection pooling, etc it will work for you.
Never used mysql so I can't comment.
Seth
I am working on an application that needs to use a local sql database. The database needs to be encapsulated in a file because they need to be able to easily move the data accross the network, onto a usb stick, burned onto a cd/dvd, etc.
Our older apps all used access, which has worked great for us, but I'd like to use the newer .net tools such as linq, which I believe just leaves sql ce edition (which doesn't seem to support x64).
How have you dealt with this issue?
SQL Compact, as of 3.5 SP1, does support x64 (and it works well for desktop apps).
Aside from compact edition, SQLite has a strong following. Not sure how well it works with linq/64-bit, though.
Not sure about what sort of performance you need on this app, but if you need your entire database to be completely portable, you could go with sqlite - .NET can hook into it, and since the entire DB will be housed in one file it would be extremely easy to move around.