Local Database with Silverlight

Question

What would be a good local database for a Silverlight application? The database's main purpose is for local data caching and synchronization services. I do not believe that SQL anywhere or SQLite will work since they use unmanaged code which will not run under the silverlight sandbox

Answer 1

VistaDB is a database that is 100% managed code, but I am not sure that is a great idea to have a silverlight embed the entire database. I think you are "supposed" to pull / post your data using webservices.

Silverlight 4 might finally change the answer to this question...

It appears from our early research that Silverlight 4 (not released and just recently announced) finally appears to support most of the ADO.NET objects so we might be able to run under the Silverlight 4 runtime. This is something we are researching and will post follow ups later with what we find.

Answer 2

@Aaron Fischer,

I'm very interested in this question too. I'm looking DB for XBAP (WPF in browser) apps. Here is my question "What embedded database with Isolated Storage support can you recommend?"

SQLite & MSSQL CE (aka SQL anywhere) wouldn't work.

VistaDB is implemented in .NET and can work under constraints (it has support for Isolated Storage) but I'm looking for alternatives.

Another option is Sybase iAnywhere - but I'm not sure how to deploy it on end-user machine.

I'm going to try DB4objects for Silverlight. If it would work, I'll update the post.

Answer 3

Based on this example it looks possible to use Google Gears and thus Sqlite. The major down side is the amount of integration work and the need to install yet one more platform on the client's computer.

Answer 4

If your caching needs are basic enough and you don't have so much data that you're doing it to minimize RAM usage, perhaps you don't even need a full-blown database. You could create an object database of sorts using a structure such as a dictionary and put into it the objects that would otherwise be your table rows. You could then serialize this data to a file in your local storage and deserialize it next time the app runs. If your data structures are done well, you could even use Linq to query your object database.

If your primary goal is to minimize the number of times you have to pull the same data from your server, this could be something to consider.

On the other hand, this isn't the way to go if you have too much data or if you make frequent writes to the database (as it would then have to serialize the whole structure to disk every time).

If you do have too much data but still want to try this, you could see if there is a logical way to partition your data into multiple files that aren't likely to be needed at the same time. Then you could push your unused data out to disk and load it back in next time the program needed it. Of course, if you take this approach too far, you'll end up essentially writing your own database system anyways.

Answer 5

I would love to see two things. 1.) Some kind of persisted local database support or 2.) Some kind of actual database server support without the hassle of web services.

Personally, I'd take Access and OleDb. :)

Answer 6

One last thing... that the database type of functionality is something Flash/Flex doesn't offer... this would be a great way for Microsoft to differitiate Silverlight and really give it a leg up.

Answer 7

Why don't use a new feature in SL 2? It is fully support in local database (like Google Gear) but of course It is not a database. You can use XML file format to keep it. pros is user just need to install SL runtime. cons; It is not a database.

Moth said in his blog about it http://www.danielmoth.com/Blog/2008/04/isolatedstorage-in-siverlight-2-beta-1.html and Dino made very good summary at http://www.ddj.com/windows/208300036?pgno=2

Answer 8

There is now a sqlite port to c# called csharp-sqlite This has promise once they find an acceptable name.

Answer 9

The answer is siaqodb. Siaqodb is real Silverlight client side object database, you can store an object with just one line of code and retrieve back objects via LINQ.For more info take a look at http://siaqodb.com

Answer 10

Yes, I think a LINQ provider is the optimal solution. As the storage space is limited, you don't really need tables and indexes, it would be convenient to have a simple way to store and query objects on the client via LINQ without having to deal with low-level file streams.