• 0

[.NET] Database for Desktop App?


Question

Hi. I'm writing a .NET / C# desktop application and want to have a database in the program. However, when I deploy my project, I don't want users to see MDF files, XSD files, or anything like that, which I believe they will if I were to insert datasets or similar things into my program. I suppose, XML files would be alright if they are in the app's directory or a user settings (like "local settings/<my app>") type of directory. What is the best way to accomplish this in .NET? I would like to be able to query the database via SQL or LINQ statements (preferrably LINQ, but SQL is good too). Also, I would like the solution to be minimal - easy setup, easy access to the data (singleton instance of the db or something like: AppDB db = new AppDB; var info = select a from info.mytable ..... ;

Link to comment
https://www.neowin.net/forum/topic/812558-net-database-for-desktop-app/
Share on other sites

12 answers to this question

Recommended Posts

  • 0

It's possible to use Access DB files (.mdb) which allows SQL statements. Though Access databases aren't really that efficient from my experience. You can also give this a look: http://sqlite.phxsoftware.com/

  Quote
* Transactions are atomic, consistent, isolated, and durable (ACID) even after system crashes and power failures.

* Zero-configuration - no setup or administration needed.

* Implements most of SQL92. (Features not supported)

* A complete database is stored in a single disk file.

* Database files can be freely shared between machines with different byte orders.

* Supports databases up to 2 terabytes (241 bytes) in size.

* Sizes of strings and BLOBs limited only by available memory.

* Small code footprint: less than 30K lines of C code, less than 250KB code space (gcc on i486)

* Faster than popular client/server database engines for most common operations.

* Simple, easy to use API.

* TCL bindings included. Bindings for many other languages available separately.

* Well-commented source code with over 95% test coverage.

* Self-contained: no external dependencies.

* Sources are in the public domain. Use for any purpose.

  • 0
  ProChefChad said:
Yes, but doesn't the access db file (.mdb) show up in my application's folder? I'm trying to avoid exposing parts/files of my program to the user.

Well if you're trying to go for a single file application you are most likely going to end up with an executable that is going to eat up a bunch of ram and grow in size as the database grows. What kind of things are you planning to store in the database anyhow? It seems to me that having a single extra file is going to give more benefits than putting everything into 1 executable. Also what other apps do is store their files in the user documents/settings folders rather than in the application folder itself -- that way you can hide those things from the average user but allow more advanced users to modify/make changes as needed.

  • 0

@dlegend: I'm just storing user-inputted data and some settings related to that user input. I don't mind the extra file so much as I mind the type of the file - I would prefer an XML file, for instance, over a mdb/mdf file. Do other programs really use mdb files locally? I searched my computer's application settings folder and didn't find any mdb files (though I don't have too many programs installed). I did find a number of XML and INI files. You're right that I don't want the exe to balloon, but I guess I'm just confused about my desktop database options within the .NET realm.

@SilverBulletUk: Thanks, I'll take a look at SQLite. I haven't heard of it before, but it looks pretty popular. Do you know how easy it is to integrate into a .NET project in general?

  • 0
  ProChefChad said:
@dlegend: I'm just storing user-inputted data and some settings related to that user input. I don't mind the extra file so much as I mind the type of the file - I would prefer an XML file, for instance, over a mdb/mdf file. Do other programs really use mdb files locally? I searched my computer's application settings folder and didn't find any mdb files (though I don't have too many programs installed). I did find a number of XML and INI files. You're right that I don't want the exe to balloon, but I guess I'm just confused about my desktop database options within the .NET realm.

@SilverBulletUk: Thanks, I'll take a look at SQLite. I haven't heard of it before, but it looks pretty popular. Do you know how easy it is to integrate into a .NET project in general?

If you aren't storing that many settings/input then it is possible to use the built-in .NET settings (via Project > [ProjectName] Properties... > Settings Tab). Here's some information on that: http://msdn.microsoft.com/en-us/library/aa...28VS.80%29.aspx. You can access/set settings by Properties.Settings.SettingName and this is a quick/easy solution if there isn't a whole lot of data you need to store.

Also, the link I sent earlier is basically a wrapper/replacement for SQLite (sqlite3.dll) which aims to make things easier (though I've never tested it) should you go with SQLite.

  • 0

I actually do use the Properties.Settings for my application settings, so I wouldn't want to cross those settings with user inputted data. In terms of how much data there will be, I'm not sure. My guess is not that much though. No more than say 500 - 1000 (for the busiest users) per table of data with only 2 or 3 tables. I just read this article: http://scottonwriting.net/sowblog/posts/3615.aspx, which doesn't really answer my question since it refers to an already existing data source, but it is an interesting read for web apps. I'm still looking for desktop application advice though with !no! pre-existing database.

  • 0

+1 for SQLite. I know there is MSSQL Compact, but SQLite doesn't require you to install anything extra, you just include a single dll file. Another cool thing is that there is a port of SQLite to 100% managed code in progress. ( http://code.google.com/p/csharp-sqlite/ )

MagicAndre1981: I haven't tried friebird with a .NET project yet. I would like to sometime, though.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.