Re: Choosing the right embedded database.


Most users would download the application and data from a website via DIAL
UP connections and would have no database package installed on their
machines. I want the footprint to be as small as possible with no
unnecessary additional files to be downloaded or installed.


If your data is rationalized, and does not fit into one table I would also recommend Firebird Embedded for this.  I use UIB and Zero's components for this.  It also instantly scales to the full client server Firebird system.


I would normally create such an application in Access but building a
distributable package means that the MDSE engine or Access runtime files
need to be distributed which runs into a 40MB download!


FB Embedded is a 1.5 meg DLL.


One facility that would be nice is for users to be able to update their
local data store via an internet link. As users "could" also add further
dance information to their local store, it maybe nice if this was a two way
procedure.


I would not recommend a two way replication for a simple application like this.  It can be done, but I am not sure given your use base if the effort is worth it.  You have two choices either to roll your own replication system, which is not trivial or use a commercial replication component or software.  I have done both, but never used them for "downloaded" software, only where installations are known and replications are scheduled between computers.  If you want to roll your own, there are Delphi systems like kbmMW that might help here.


Is any of this actually possible with an embedded system?

Yes. Both a one way and two way are possible, but a two way would require a great deal of work to implement if you do not buy a commercial replication system. A one way replication, server to client, would be far more robust and not difficult to build yourself into your application, if you plan your database structure well, using something like Indy to move data. A one way system is also just a good starting point to learn the ropes. I would also only recommend this be done as a web service (you can use what you like: Delphi, Java, PHP, etc.), not as a direct database replication system. I would not recommend allowing direct connections to your central database for numerous reasons. The benefit of a web service also affords you the luxury of using different database systems on the client and server since they do not connect directly. Why would you want to do this? For example MySQL is common with ISP web services providers and you can store your server based data in MySQL, but MySQL is not something you want to install on a client computer. Keeping your SQL to simple standards then also means you can even use the same SQL code to built and query tables on either MySQL on the server or locally with the Firebird engine.

Kevin
--

Software for resource managers and researchers
www.ecostats.com
.