> 1) - Disconnect from the server DB (FB 1.5 in Superserver mode)
> 2) - Take there laptop out into the field and edit documents and or
> create new ones
> 3) - Connect back into the server and upload new or changed documents.

> So first question - How does one swap between embedded version and
> server version at runtime
>
> Next question - the big one, how does one implement replication.
>
> What are the gotchas, for example how do we control the number
> generators that create the PK numbers. Wont the get all out of wacko

Hi Grant,

while I'm sure others will give you some good FireBird answers to these
questions, if it is a new app you might like to consider using a multi-tier
framework (like RemObjects/DataAbstract, kbmmw, etc) with Firebird as the DB
backend. Both RO/DA and kbmmw have facilities for easily switching between
briefcase mode and server mode and handling the replication.

The main reason I suggest these frameworks is that they keep track of the
'delta' log of changes, and can persist them to local memory tables, local
databases, or to file.

However, you may be able to achieve your goals by writing the data to a set
of in-memory tables such as the kbmmw memtable when offline, and simply
copying the memtables dataset into a firebird dataaccess component dataset
when you want to do your replication and commiting them to the server. This
assumes of course that nothing else will have changed the data in the
meanwhile. If something may have, you need more complex logic, and a proper
n-tier framework may be necessary.

Anyway, just a suggestion. I'm sure you'll get more FB-specific answers
here.

Lauchlan Mackinnon