The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Database in a shrinkwrap application - which one?

I Have an application I sell that has a VB6 UI, with some DLLs written in VC++ doing much of the core processing. I have a data layer on the VB6 side doing the data read/write, and use ADODC.Recordsets to XML files to store program data. I am quickly seeing that this method of data storage is getting unweidly as the application has grown in features and functionality. My question is:

Does anybody have suggestions on a good database to use in place of this?  My app is small (less than 6 meg), and any database engine would have to be small as well - I don't expect customers to want to download a 6 meg program with a 50 meg database installer attached.
Robodale Send private email
Monday, September 19, 2005
 
 
Well, it rather depends on the amount of data you'd expect to be storing, and whether you're expecting concurrent access (how good does the locking code need to be essentially). If it's relatively small, how about an Access database? Should work quite happily on pretty much all Windows systems.

More information would be needed for any more specific answers though...
Andrew Cherry Send private email
Monday, September 19, 2005
 
 
> Does anybody have suggestions on a good database to use in place of this? 

You neglect to say if this is single-user or multi-user; local access or over a network or with a server.  So I can only list a few possibilities:

SQLite (www.sqlite.org) is very small (300k), a single dll,  stores data in a single file, and is open-source.

CodeBase (www.codebase.com) offers dBase/Foxpro compatible file formats.

Firebird (www.ibphoenix) is open-source.  It's a much more complete SQL database that SQLite.  Look at the embedded version.

I'm curious.  Why have you discarded the Jet engine (ms-access)?

-- Art
Art Metz Send private email
Monday, September 19, 2005
 
 
Thanks for the comments so far:

@Andrew Cherry
So far I have not yet seen users have more than a couple thousand rows.  I doubt anybody would be writing more than 5-10 thousand rows. So far, it is a standalone application - only 1 user to database is required....but I might be making a server version, so support for more than one user may be required, plus over a network.

@Art Metz
I had used Access in version 1.0, but ditched that for XML files in the next version.  I just could not get the speed I wanted with Access.  Granted, I am making more efficient use of data like caching and such in the current version, but in the end I was always worried about their access database corrupting in version 1.0.
Robodale Send private email
Monday, September 19, 2005
 
 
I'm currently looking at VistaDB. The things I like are:
- small footprint (0.5MB)
- large capacity
- low cost
- ease of deployment

http://www.vistadb.net/vistadb_features.asp
Nick Hebb Send private email
Monday, September 19, 2005
 
 
All of the complaints about Jet database corruption does make me wonder...

Since the biggest source of this is client machines shutting down or losing connectivity abruptly during update actions, does anyone know how SQLite, dBase/Foxpro, etc. perform under similar circumstances?  Anything solid?
Cur Mudgeon
Monday, September 19, 2005
 
 
Yea, I'd love to hear more opinions about this as well.
Robodale Send private email
Monday, September 19, 2005
 
 
Cur Mudgeon > Since the biggest source of this is client machines shutting down or losing connectivity abruptly during update actions, does anyone know how SQLite, dBase/Foxpro, etc. perform under similar circumstances?

As far as SQLite is concerned, just make sure all write operations are made as part of a transaction, so that if the computer goes south during a transaction, SQLite will cancel the operation.

More infos at http://www.sqlite.org/support.html
Fred
Monday, September 19, 2005
 
 
My vote also goes to Sqlite. The Zeus editor uses Sqlite to store its code completion and class browsing information and it does this job extremely well.

> Since the biggest source of this is client machines
> shutting down or losing connectivity abruptly during
> update actions, does anyone know how SQLite, dBase/
> Foxpro, etc. perform under similar circumstances? 

Sqlite has support for transaction processing, so provided your design is solid this should be a problem.
Jussi Jumppanen
Monday, September 19, 2005
 
 
We make VistaDB, which is an alternative to Jet and SQL Server for building small to midsize applications. VistaDB supports both SQL commands and Direct Data Access(tm) objects that let you manage the data directly without SQL.

VistaDB is geared towards developers building .NET (C#, VB.NET, Delphi.NET), COM and Win32 VCL applications. Win32, WinForms, ASP.NET and the Compact Framework are supported.

The core VistaDB engine is only 400KB. With the ADO.NET Provider, the total VistaDB footprint is only ~550KB (2 DLLS: engine + provider). VistaDB is very easy to deploy. Basically Xcopy or FTP these 2 dlls to the target machine along with your application and database, and you're done. We also have a new VistaDB Server that can optionally be used to provide access to data on a remote computer over TCP/IP.

Feel free to check out our web site and see if this is a good fit for your needs.

Anthony Carrabino
www.vistadb.net
Anthony Carrabino Send private email
Tuesday, September 20, 2005
 
 
With transaction buffering and the like I find corruption in Visual Foxpro tables to be pretty rare, the most likely place for corruption to happen is in memo files as they're a kind of threaded list.

Very occasionally an index might become corrupt and need to be rebuilt and less often than that the last record of a table might be corrupted and surgery attempted to fix up the table length.  There are tools for that but I can count on the fingers of one hand the number of times I've had to use it in the last ten years.

Unlike a Dbase II app in around 82-83 that corrupted every lunch time when the user switched off her machine.
Simon Lucy Send private email
Tuesday, September 20, 2005
 
 
@Anthony

Thank you for the info about VistaDB.  I'll check it out when I do my architecture planning in early October.
Robodale Send private email
Tuesday, September 20, 2005
 
 
+1 sqlite

Nice API, small footprint, 0 hassle deployment.  Supports transactions, so you can guard against corruption.
Lou Franco Send private email
Tuesday, September 20, 2005
 
 
Does SQLite have a non-C/C++ API?. Just curious since the OP's data access code base is in VB6.
Nick Hebb Send private email
Tuesday, September 20, 2005
 
 
MYOB uses Access (with DAO).
Marcus from Melbourne
Tuesday, September 20, 2005
 
 
Do not use CodeBase.  Avoid it at all costs, particularly if you are going to talk to it through ODBC.  If you don't use their native language (not SQL), then you are going to take a huge performance hit.  I experienced this at my last workplace.  We ended up switching to MSDE.
Joshua Volz Send private email
Wednesday, September 21, 2005
 
 
I've used MS Access in the past, but have recently switched to Firebird.  In addition to the corruption problems with Access, I've started seeing more missing dependency issues, as MS has stopped including JET in MDAC.  Shipping all of the required dependencies for all of the OS versions adds about 30 MB (if you're using a single installer for all OS versions).

Firebird on the other hand requires less than 2mb of dependant files - xcopy deployment, no registration required - yeah!

Wednesday, September 21, 2005
 
 
There are so many articles about how to prevent and/or deal with Access corruption eg.
http://www.kzsoftware.com/articles/PreventAccessDatabaseCorruption.htm

Although there are lots of "solutions", you don't see these same articles for databases like SQLLite or Firebird.  I don't know if that's because the market penetration is lower, or because these other databases just don't have the same problems...

Wednesday, September 21, 2005
 
 
I've heard very good things from multiple sources about Firebird. (It was open sourced by Borland years ago, noe supported by an active user community).

Some pluses:
* No install needed. Just plop one file on the machine and you'r done.
* Fairly small (I'm remembering <5 MB, but I could be wrong).

serach on "firebird database delphi". Can be used with other programming languages, I believe.
Mr. Analogy {Shrinkwrap ISV} Send private email
Thursday, September 22, 2005
 
 
Yeah, it works with .NET as well (there's an ado.net provider - ~1.7 mb total!)

Thursday, September 22, 2005
 
 
I'm just curious why no one here recommends mysql. Though I can't recommend i'm not a mysql user either. I'm just starting learning it. (For cheaper alternatives.)
j2e
Friday, September 23, 2005
 
 
j2e asked:
> I'm just curious why no one here recommends mysql.

Because it offers all the disadvantages of a server-based dbms (install and admin issues) with all the disadvantages of Access (not ACID, no real transactions, no real SPs).  Don't tell me this will be fixed in version 5.0; the OP wanted something usable now.

If you're going to use a server-based product, use FireBird.  It's a little weak in the SP area, but it's not clear the OP needs or wants to use SPs.

Art
Art Metz Send private email
Friday, September 23, 2005
 
 
MSDE.

It's the SQL Server Engine. The onlything you don't get is a clicky interface. Perfect for embedding.
Shane Harter Send private email
Wednesday, September 28, 2005
 
 
MSDE isn't "embeddable" in any meaningful sense of the term. 

You can include installation of MSDE as part of the installer for your main app, but it's installed as a separate application and adds a huge amount to download size.  Most of the embeddable solutions discussed in this thread add less than 1MB to a download.  Not sure how much MSDE adds but I believe the MSDE installer is on order of 40MB to 50MB.  Not a good choice for downloadable shrinkwrap.

Just as importantly, after installation MSDE needs to run as a database server in a separate process from your shrinkwrap app.  You will either need to train uses on how to start MSDE up separately or include code in your application to somehow start and stop the server process. 

Not saying MSDE isn't a good solution in some cases.  But it's not embeddable.  And my feeling is that while it may be a good solution for many "custom" db applications, it's a bad solution for true "shrinkwrap" applications.
Herbert Sitz Send private email
Thursday, September 29, 2005
 
 
Wouldn't there be additional licensing required if you went the Access route?

Friday, September 30, 2005
 
 
" Wouldn't there be additional licensing required if you went the Access route?"

Yes, if you're actually shipping an application that needs Access to run as a front end to the Access/Jet db.  In that case your users would have to have Access (preferably same version) or you would need to package and ship with an Access runtime, which you could get royalty free license for with MS Office Developer version (not expensive, less than $1k, but runtime is many, many megabytes, around 50MB now if I recall, used to be even bigger).

No, if you're just shipping a Jet mdb to be used as backend for VB or other front end program.  Access itself comprises the Access front end stuff (that you see) and the Jet database engine where data is stored.  The Jet database engine will be availalbe on any computer that has MDAC installed.  MDAC was included by default on most Windows installations until very recently, can still be downloaded and installed for free from MS website.  You may come across version problems on older computers, though.
Herbert Sitz Send private email
Friday, September 30, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz