>>Any comments on this?
>>
>>When an update, insert, or delete occurs, the transaction is logged to a
>>transaction table.
>>
>> tr_log (datetime, tr_id, table, key, tr_type, command)
>
> I'm kind of interested in how you'll do this without triggers in a .DBC. I know it can be done, but I'm guessing it'll really limit how you can manipulate tables.

All table updates would have to go through wrapper functions (a real pain).
Since the CodeBase routines only update two fields, timer presets and analog limits, maybe I can get the C++ to use VFP COM for the updates. This will allow me to use triggers.


>
>>
>>The transaction log has two child tables that log the peers that have
>>executed the transaction. The are global and local tables. The global
>>table gets cleared when all peers have processed the transaction.
>>
>> g_tr_exec (datetime, id, peer_id)
>> ------------
>>
>>The local table is only cleared when all peers are online and no peers
>>have tr_log rows. This table prevents the peer from reexecuting an old
>>transaction.
>>
>> l_tr_exec (datetime, id)
>> ------------
>>
>>The peer logging the transaction will create g_tr_exec and l_tr_exec rows
>>when it creates the tr_log entry (it has already executed the command).
>>The new tr_log and g_tr_exec rows are forwarded to each online peer. Each
>>online peer will execute the command and create their own g_tr_exec row,
>>which is forwarded to all online peers. When a tr_log row has a g_tr_exec
>>child for every peer, the tr_log row and tr_exec children are deleted.
>
> I would probably opt for "pull" updating instead of "push". Both should work, but I think it'd be easier to let each station be responsible for updating it's own information rather than the other machines. I'm also wondering why each machines transaction list is sent to all the machines. They don't need that information, and it looks like you might be increasing the number of places where something could go wrong. Of course, you are replicating to more than one machine, increasing redundancy, which might have the opposite effect. I dunno.

On startup a node would pull updates from all its online peers, after that update notifications would have to be pushed to keep the data the same. Each peer needs to merge its transaction log with all online peers to prevent the following scenario:

peer 3 is offline
operator changes table on peer1
peer 2 adds the transaction and logs it
peer 1 goes offline
peer 3 goes online

If peer 2 does not maintain a list of peer 1's transactions, peer 3 won't know about the transactions until peer 1 is online at the same time.