Jon Galloway

Check BerkeleyDB (http://www.sleepycat.com/) there are several wrappers around the net for using it with c#

Perhaps MS Access

There is also Firebird :
- http://firebird.sourceforge.net/
- http://www.dotnetfirebird.org/

I'll second Firebird as an embedded DB or even as a regular replacement DB.

SQLite is very nice though I do admit.

VistaDB maybe.

Have you looked at running SqlCE on your Windows platform? I believe it works on CE devices as well as tablet pcs. I have been told it runs on all windows platforms, but it only is licensed on the CE and tablet pcs.

Wally

SQLIMDB from Quilogic is pretty good but purely IMDB. Check www.quilogic.cc

http://www.codeproject.com/cs/database/EmbeddedFirebird.asp

I would offer db4o http://www.db4o.com/ for embedded database. It is very easy to use though I did not evaluated more throughly. I only used it to make a homework for my master programme.

Man... here I am on my continuing search for an embedded database, and I run across a page that links to the chronicle of my continuing search for an embedded database. :o)

Well, I've tried everything that everyone above has mentioned (all had some kind of shortcoming, be it major or minor)... but I'm in a different position than I was when I wrote the post that was linked to.

When I originally wrote that, I had been working with embedded DB's for all of about three and a half seconds, so I made a few false assumptions. One of those assumptions was that it was possible to use an embedded db and have more than one process connect to it. This goes against the inherent nature of the embedded db (duh :op)... so I gave up on that requirement. I now would just like to have a thread-safe db with a .NET provider that is available in a .NET source code, so I can put it right in my app (the latter is just preference, though... I'm willing to accept anything at this point :op).


Firebird WILL work... I actually used it as a test backend for a bit, but it requires two DLLs (the .NET provider and the engine dll) and it's larger than the other options (FB's 2MB vs others' ~250KB). Those aren’t show stoppers, though, and if none of my other options pan out, then I may go back to it.

SQLite still won't work because it's utterly non-thread safe (despite what they say) and it also requires two dlls (which isn't a big deal, but still I'm trying to find a way around that).

VistaDB costs money..... 'nuff said. :oP

db4o is an object db.... I need one to handle SQL. It also has some weird quirks like storing BLOBs outside of the database in individual files (whuh???) and since most of my objects are stored using binary serialization, I'd have a heck of a lot of extra files.

BerkeleyDB does not have a .NET provider. The Berkely XML DB does (available from a third party) but who the heck wants to use XML for data storage? :OP


So... after all that, you're probably thinking that there will be some good news, right? ......well there isn't. There is some POTENTIALLY good news, though. :o)


I've been using SharpHSQL for the last month-ish while doing improvements to my app, so at the moment, it is a functioning backend db. It is very thread safe (tested it every way from Sunday in that respect), it has a .NET provider, and it is entirely written in C#... and to top it all off, it's really small (~200KB or so compiled). So here's where you'd be asking yourself, "So what's the problem??" Well... the problem is, it's still a little buggy. The bug I mentioned in the linked post has been fixed... the .NET provider now works when storing binary data types, but other problems still exist. One of which is committing transactions. If I execute a series of SQL commands and then kill the app, the last command (or two.. or whatever) that was run is not maintained... even if I use BEGIN TRAN and COMMIT after each statement... which leads to data consistency issues (such as objects stored in the db that the user can't see because only half of the transaction "survived" the app kill). The other issue is corruption of the db that happens when killing the app. Sometimes, not always (very flaky), after killing the app, you can't open the db again... something about corruption of a cfg file. So that's a big problem... Windows locks up and the user has to force a restart, and when they get back, the backend of my app is entirely corrupted (*yeesh*). It has a couple annoyances as well that I had to get around. It uses a number of db files, one of which is a transaction log file which is a plain text file!! So you can see every single transaction being done on the database, including login... so don't bother using SharpHSQL if you need a secured backend... the user can open the log file using Notepad and see what the passwords are. :oP Anyway... the point of saying all this is... the guy keeping it up has been responsive so far in fixing every bug that I've found (which has been nice), but he's kinda stalled on this app termination issue. If he can get that bit worked out, I'd be perfectly willing to use SharpHSQL because it meets all my primary requirements and has shown good performance in the general use it's been getting over the last number of weeks.

The other potential DB (that I just stumbled on) is called Minosse (http://www.codeproject.com/cs/database/minosse.asp). It looks like an ambitious project, and it appears to meet my requirements, but it's still in its infancy (and I’m not even sure if it's still being maintained). In addition, I haven't even downloaded it yet to see if it's thread-safe... so basically, consider this a beta recommendation.



Anyway... as always... if anyone knows of any other options out there... I'm all ears.


WATYF

Well the hits just keep on coming...

I tried Minosse.... couldn't even get it to create a database... using their own sample code... *ack*

And to top it all off, I just found out that firebird's embedded version can't be run on a network drive (which my app is sometimes run from)... so there goes my fall-back option.


*sigh*


Doesn't anyone make a database that doesn't have some kind of critical flaw?



WATYF

It is a file operation. Fast and stable, I used it on my system(C & Java). It is simple ,not depends on other DLL. Open the file and you can INSERT, UPDATE, DELETE a (key,value) pair.
It is really small. not more than 100K.
If you want to try, you can give a email to me : forest_luo@21cn.com

Just take a look at http://www.daffodildb.com this might solve your problem though its a java DB but given an ODBC driver to interact with MS Platforms

db4o http://www.db4o.com">http://www.db4o.com does not force you to store blobs in external files, this is only an option, to allow you to keep your main database file smaller, if you like to do that. You can also store byte arrays in the main file, just like any other object.

Using binary serialization to store objects, as you are planning to do, is not a good idea. Your system will break if you modify classes. db4o takes care of this problem for you by updating it's internal schema automatically, whenever you modify your classes, you do not even have to run any reorganisation on existing database files.
--
Carl Rosenberger
Chief Software Architect
db4objects Inc.
http://www.db4o.com">http://www.db4o.com

I see what you're saying, but that's not how I'm applying it. I'm using binary serialization to dynamically store objects. It enumerates the properties of the controls on the object and adds each one to a serializable object, then serializes that object to a BLOB in a table. The opposite happens when the object is restored. I can change the class (in this case, forms) as much as I like, and it will adapt.

This is really a hack way to do it, though. Partly, because I *am* a hack :op, and also, because it's basically an evolution of how the objects were originally persisted, and since I didn't feel like rewriting the entire app persistence, I kind just piggy-backed the original method (binary serialization) onto a database and made it dynamic. So I'm not recommending it as an ideal method, but it works well for me.

Thanks for the info on db4o (I see you're associated with the project, so sorry for the slight misinformation)... That was just something I had read on your site (or elsewhere... can't remember), but I hadn't really run into that issue myself. My main problem with db4o was that it wasn't SQL based. If I just needed object persistence, then I may have gone that route... but I store other data (variable and otherwise) in the DB as well.



It looks like I'm going with SharpHSQL, btw. I put up a post on my blog (http://www.musicalnerdery.com/index.php?option=com_content&task=view&id=24&Itemid=9) explaining the latest developement. It looks like that's my best bet so far.



WATYF

After many years, we have the solution:

<b>VistaDB 3.0 is a 100% fully managed and typesafe SQL database for Microsoft .NET and Compact Framework</b>. VistaDB 3.0 has been redesigned and redeveloped entirely in fully managed C# code. It was _not_ ported from our 2.x code set.

Key features include:

- SQL Server 2005 syntax compatible

- 600KB footprint managed assembly

- Unicode and rich data types

- and much more.

Read all about here:

http://www.vistadb.net

Anthony Carrabino

www.vistadb.net

Stay clear of Vista. I've used the "stable" version and it bombs out after a while. We purchased it and we developed a sweet disconnected app- then right before launch Vista started to crap out. For the last month I've had no help from their support. So now our app is over a month behind schedule and I look like crap because of Vista - I would recommend keeping clear of that pile.

Too bad MS Access won't work.

Using OleDb I can connect to it but it doesn't seem to know SQL very well at all.

I can execute statements in the MS Access query builder just fine. The same statements through OleDb are crashing.

How close is Firebird's SQL to MySQL?

Please take a look at Perst for .NET.  It is an embedded database that is thread-safe and supports multiple processes, and has a simple SQL interface.

Has anyone thought about going back to using ini files?

They were good on Windows 3.1

VistaDB 3.0 is the right database solution for .NET:

- Developed in pure C#

- Fully managed and typesafe (i.e. apps pverify)

- Small 600kb footprint

- 100% embeddable using ILMerge

- Supports .NET, CF and Mono natively

- T-SQL compatible SQL syntax and SQL Server compatible data types

- Deep integration into Visual Studio 2005

Dave Gorman's post above is based on our old VistaDB 2.1 version, not on our new VistaDB 3.0 which has been completely redesigned and redeveloped from scratch using C#. The original issue is posted here:

http://www.vistadb.net/issuelist.asp?issueid=1317

We recognized that our 2.x product line had some shortcomings, especially the 2.x SQL query processor. That's why we invested in a total rewrite. FYI, this issue no longer exists in 3.0.

We can't change past experiences but we've worked very hard to make 3.0 into a great product for the future.

Anthony Carrabino

www.vistadb.net

This is a C# wrapper for Berkley embedded db:

Berkeley DB for .NET

http://sourceforge.net/projects/libdb-dotnet

How about ScimoreDB embedded database? Installation is pretty simple. It is single Dll that you need to include with your binaries. There are samples for .NET applications.

Read more: http://www.scimore.com

This is long lingered problem I have not solved yet. After month of frustrating struggling with various things (Firebird, db4o, ...) I'v return to Ms Jet! I always have new problems with it! Strange mathematical behavior; crash; compacting; ... puffff!

I wonder why this is so?!!

Is anyone developing a real world application that needs an embedded DB??? Sure! But I mean why this problem is not going to be solved?

I created a .NET Windows application that required an embedded database. After seeing this blog I decided to try Firebird embedded.

YES!! It's real light weight, uses standard ANSI SQL (more or less) and so far it's plenty quick enough.

I found a couple small drawbacks - it's difficult to get unique for a combination of a lot of fields.

The newer version claims to solve that but I can't find drivers for .NET.

Overall, I'm real happy with it and have settled on it as the final database for this .NET 2.0 app.

Has anyone considered porting Java DB (AKA Apache Derby (AKA Cloudscape)) to C#? I have not found bad anything about it (only good things), and I would imagine porting Java DB to C# would be rather easy. It also has the backing of 3 major parties: IBM, Apache and Novell, so i think it should be stable.

I did found an article on how to have ADO.NET interface with Java DB (Cloudscape) but the process seemed a little involved. And I would rather have my Applications to be completely .NET

MySql Embedded. Full feature. Free and open if your end product is. Optionally OEM license if your product is commercial.

difference between *.fdb and *.gdb in firebird

firebird 2.0 rulez

test with 5 processes (main thread + 4 background workers) accessing it.

www.youtube.com/watch

:)

Did you try scimoredb?. I too am in a dilemma and am planning to use scimore. I think we have to create a perfect DAL

I managed to get the java H2 database running in C# using IKVM.Net.

It converted the .Jar file into a .Net Dll file and ran perfectly.

Even .Net  triggers and .Net User defined functions worked in the database.

Since IKVM converts java bytecode into MSIL there should be only a small performance hit, if any.

SQL Server compact edition seems to be a good choice ? Only 2Mb footprint and can even be synchronized with a back end using the new Synch libraries and ADO.NET

I Created a Ado.Net wrapper for H2 and called it H2Sharp check it out:

http://h2sharp.googlecode.com/

it uses IKVM.Net.

www.codeproject.com/.../EmbeddedFirebird.aspx

they have .net specific plugins so you can just drop the db right into your code, no problem.

Pingback from  We need an Embedded Database for .NET applications - Jon Galloway &laquo; Mortovski&#8217;s Notes

I was wondering what the original postie finally used and how did it go.

scimore is very good and free, and have the .net conector www.scimore.com/.../index.html

Has anyone tried Embedded MySQL?

I am looking for an embedded database that can store about 5 million rows. Luckily the table that stores the 5 mil rows can be read only.

I was planning to use two embedded databases. one for the large data set and one for everything else. Has anyone tried any of the databases mentioned here with such a large dataset?