Take the 2-minute tour ×

I have a to create an application using C# for the Windows Platform.

Normally all of the work I've done was on a single machine: It had Visual Studio 2010, Microsoft SQL Server and a range of other tools.

If I use Entity Framework for example, I know it'll work because I have a SQL engine installed.

Here comes my problem and the point of this question:

  1. What would you use to save information? This software will be sold to various 3rd party companies and I can't imagine going company to company installing the SQL Server, then the tables, and then, finally it would work. It needs to Just Work™

  2. I need to be able to search through the 'records'; by dates, ID's, names, locations, etc. Using SQL would be pretty easy, but I fall back to the problem of numbers 1.

I'm sure I'm missing something every dev learns at some point so thank you in advance for the guidance.

Edit: Missed the most important part of the question, what's the project?

Basically it saves information from a receipt, then you can scan the receipt (I'll use the Office API for this), and associate that scan to the entry entered earlier. So it would be ID, Name, Amount, ScannedImage. In a nutshell.

Edit 2: Another bit of important information:

This will only have a single concurrent user and whatever persistance tool I use it must be able to save large quantities of information. I don't really know how much space plaintext with the ocassional image would take up, but I'd rather have extra room than have a want for more room.

share|improve this question

closed as not constructive by casperOne Jun 13 '12 at 13:31


Is this will be client-server app or just client's workplace without any cuncurrent user's updates? –  Nick Martyshchenko Oct 25 '10 at 21:16
Completely and utterly independent. The will only interact with himself. –  delete Oct 25 '10 at 21:17
Go with SQLite then as all here suggested :) –  Nick Martyshchenko Oct 25 '10 at 21:24
You may want to consider abstracting the data access in case you need to change it later. Requirements like "This will only have a single concurrent user" frequently change, I've found. Even if you use an O/RM like EF, consider limiting the number of classes that depend on it. –  TrueWill Oct 26 '10 at 1:32
One very easy way to avoid becoming dependent on a specific DB is by using OLE DB. –  Brian Oct 26 '10 at 13:06

7 Answers 7

You may take a look at SQLite. It's portable, don't need to install anything and it is supported by common ORMs.

share|improve this answer
+1 for SQLite. It is a ridiculously simple ACID compliant Db –  Byron Whitlock Oct 25 '10 at 21:15
Yeap, and already used by many applications such as Skype and Google Chrome browser. –  Darin Dimitrov Oct 25 '10 at 21:17
+1 . If you already know how to use MS SQL, figuring out SQLite should be really easy. Installation is just a matter of including a dll in your project and the database is just a file. –  Brian Oct 25 '10 at 21:21
+1. It also supports in-memory database instantiation, which gives you a great performance boost when you have a bunch of unit tests. Compared to a full-blown SQL Server, however, it will still be slower when using a disk db, but hey - it's a zero configuration db, you cannot expect it to do wonders. –  Groo Oct 27 '10 at 16:34

you can automatically install sql server express edition and programmatically setup the SQL database at install time. This is common practice

if you dont need all the bells and whistls of SQL server then use SQL compact edition. THis is much simpler to install but is not multi-user etc.

SQLite is cool too

SQL express is limited to 4gb. SO another common tactic is to default to doing sql express install and database setup but allow user to choose existing sql server installation and you then just setup the DB (using the same setup code)

You should tell us how much data , how many users, etc.

share|improve this answer
If memory serves, SQL Express also has a size limitation (somewhere around 2GB per database). –  Mike Hofer Oct 25 '10 at 21:12
SQL Server is a wonderful piece of software. But SQL Server CE is a huge piece of garbage. stay away. –  Byron Whitlock Oct 25 '10 at 21:13
small POG...... –  pm100 Oct 25 '10 at 21:15
SQL Express 2008 R2 limited to 10GB –  Nick Martyshchenko Oct 25 '10 at 21:20
SQL Server Express is more likely to have pain during installation than SQLite as it uses fun stuff like services. The frequency of clients unable to get the software working will probably be much lower with SQLite. –  Brian Oct 25 '10 at 21:30

If you are prepared to look at something outside of the SQL square you might want to look at a document centric database such as RavenDB or MongoDB

Congratulations on going out on your own.

share|improve this answer
I was thinking the same. If I was in Sergio's shooes I'd have a go at something other than SQL. Just for the fun of it and learning something new :) –  Paw Baltzersen Oct 25 '10 at 22:22
@Paw That was part of my thinking :). My primary reason was that the idea of a receipt is quite a flexible one and a document DB could be a better fit for the potentially fluid\unstructured nature of the domain. –  Adrian Russell Oct 25 '10 at 22:26

I've used Firebird on a couple projects. It can be xcopy deployed and, if needs change, can also become a decent server. It runs on Linux and MacOSX if needed (using Mono for the .Net implementation).

This is just to provide an additional option. SQLite looks like a good option too.

share|improve this answer

I'm going to take a wild and crazy risk here and make a completely ludicrous suggestion.

Have you seriously considered XML as your data store? LINQ to XML makes querying this stuff a snap and it's highly performant. No additional installation is required to support it. It satisfies your It Just Works™ requirement. That just leaves the disk space issue.

However, disk space is cheap. And with the space you'll be saving from additional software installations, you might not have as much to worry about as you think.

It's an option worth considering (or reconsidering).

Just throwing that out there.

share|improve this answer
This was my initial thought, and implementing it would be trivial, but I'm hesitant because of the searching necessity I need. CAN you search XML by dates, ids and other strings? –  delete Oct 25 '10 at 23:02
For an amazingly simple tutorial that demonstrates how this can be achieved in a typesafe way, see here: joe-stevens.com/2010/01/08/linq-to-xml-tutorial. And, once you have the objects in an enumerable list, you can use LINQ to objects to further filter the list down by dates or other types. –  Mike Hofer Oct 26 '10 at 11:28

If you use .net i think easiest way is setup a Sql Server Compact database, its a kind of sqlite but made by microsoft, easy to integrate to VS .Net.

Under is the description paste from the site http://www.microsoft.com/sqlserver/2008/en/us/compact.aspx where you can download it free.

Embedded Database for Building Client Applications


Top Features

  • Free to use and distribute
  • Supports desktops and mobile devices
  • Small footprint for easy deployment
  • Fully embeddable architecture
  • No administration required
  • Single file, code-free database format
  • Supports all Microsoft Windows embedded, mobile, desktop, and server operating systems
  • Supports a rich subset of Transact-SQL syntax and SQL Server data types
  • Microsoft Visual Studio 2008 integration
  • Supports ADO.NET, LINQ to SQL, LINQ to Entities, and the ADO.NET Entity Framework
  • Supports multiple concurrent local connections
share|improve this answer
Check SQLite vs. SQL CE bit.ly/biBmoG, SQLite vs. SQLCE vs. ? in a Mobile Application - Stack Overflow bit.ly/cZHnw1 –  Nick Martyshchenko Oct 26 '10 at 13:13

With all details you provide, embedded databases will be best solution, go with System.Data.SQLite.

share|improve this answer
See new edit by OP (made after you posted). With only one concurrent user, I don't think peak load is a concern. –  Brian Oct 25 '10 at 21:28
Thanks @Brian, but I commented his post (go with SQLite), 4 min before you point me in comment :) Ok, I change my answer too. –  Nick Martyshchenko Oct 25 '10 at 21:53