Thank you for the pointer to Berkeley DB. Having read portions of the tutorial, I can assure you that knowing about this when I began the project would've saved me hours of coding! And yet this one quote from that tutorial gives me pause:

Berkeley DB replication groups consist of some number of independently configured database environments. There is a single master database environment and one or more client database environments. Master environments support both database reads and writes; client environments support only database reads.

This speaks directly to my synchronization issue, as it will be necessary to modify a client (clone) database offline for later synchronization to the master. This is necessary during data entry, for example, since our data entry person is a volunteer working at home with a dial-up internet connection. For her to do her work while maintaining the persistent connection required by a purely transactional system is expecting too much. Better, would be for her to have a clone of the master database which gets modified. When she connects to the server, those modifications would get uploaded and any changes made in the interim to the master database would get downloaded. Synchronization conflicts occur when the same record (or field) gets changed in two different copies of the database. They can either be logged for later human intervention or dealt with algorithmically.

What I was hoping for was a module which automated the synchronization bookkeeping with hooks to the main program for dealing with conflicts. One that also includes journaling for reversing changes would be a plus.