David, <I have devoured Anne Gillihans Inside R:Base and am now thinking euthanasia is the next best move!> Don't go jumping off any bridges or standing on train tracks! It wasn't easy at all but can be done with a great deal of effort! It was must have at the time! If I had to do it again I would do the accessing via the Internet using Oterro and Tango(faster approach)! Or PC Anywhere to a dedicated PC's at the Main Office(slower approach)! Best Regards, Oma P.S. This is how I resolved this multi-database issues with a school tax auditing client! It wasn't easy but it just took time! All client creation is on the main database in the office never on the remote databases! (if client creation is needed then have a new client table in the mobile PC's DB which provides for a temporary number for that client, upon running the transfer processing of this new client's data and for all other entries using temporary numbers be transferred to Office DB creating a new ID for client and changing the temporary numbers to the new final number in what ever data you entered new) Any deletions of information occurs on the Main Office DB with proper rights! Added tags columns for all tables that could be changed by the field agents and in the main database! (set userID,Date,Time) Identified static tables that will only have one row of data for each client (added a unique row ID) Identified dynamic tables that will have many rows of data for each client (in these tables we added a row unique ID number for comparison of edited rows) Reviewed the data access needs on the mobile PC's versus the Main Office Database. reduced the main office code and adapted to the needs for the mobile PC's!(sub set of main program) changed code in the main office and mobile PC's to update id values for changes or new entries (at the time didn't understand triggers that well but would have used them instead if I was doing this today) Transfer programs would be run weekly by the mobile PC's. The mobile PC's DB would be unloaded to the Main Office PC for further processing The mobile PC's unloaded DB on the Main Office PC would be reloaded to recreate the Mobile DB's on the Main Office PC Transfer Processing(this is a go do something else for awhile process) - Unload Main Office DB Before Processing - create each mobile database by reloading - process new entries in each of the databases - process edited items in each of the databases - report on items that have been edited by both mobile PC's or Main Office PC and one of the Mobile PC's (if these edits or new entries are in a static table then they are placed in a holding table for someone to determine with will be the single entry in the static table. If the record ID no's match then you do the same for dynamic tables!) Then run update process on the Mobile PC's coping and renaming the Main Office DB to the Mobile DB. It was a lot of work but because they have a very defined structure and small number of tables in their DB it wasn't to hard to handle all the what if's! If a transfer or update process fails there is a recover routine to put the pieces back together and try again! I keep current history of all DB's in unloaded form before processing and they don't get over written but unload files do get delete after on week on mobile PC's and after two weeks for the Main PC!
