Randall,

Without looking at your store job, restore job and netbase stop/start procedures I can only assume at this time that the main problem between a successful and unsuccessful sync of your databases is due to a timing problem somewhere in your procedure steps.  A flush is happening too soon or too late between the time you start your backup and the time posting starts.  I have had to work this problem several times and became familiar with the potential problems.  Once one or two records are processed or being processed again the data sets (individually) will become out of sync.  You may also have some problems if you have any jumbo data sets on the restore end of your process.

Tom Renz

>>> Randall Davis <[log in to unmask]> 09/29/99 09:39AM >>>

I have been attempting to synchronize (Netbase Shadow) my 2 3k systems
for a week now.  Three attempts, three failures.  Quest suggests that I
am doing everything properly.  My suspect now is TurboStore.  I am a
7/24 shop, in that we're an e-commerce company, and my HP3000 is linked
to the front end web site, and is integral to our order capture
process.  Thus, no down time is allowed for any reason.  TurboStore was
purchased before I joined, and based on my understanding of the "true
online" version of the product began using it for backups.  All my
attempts at synchronization were using backups created while users were
accessing the system.  After talking with a few people, I've begun to
suspect that TurboStore only provides a real online solution for
Image/SQL if the application has been built with logical transactions
(i.e. DBBEGINs and DBENDs).  Since my application does not, the
transactions are not queued by TurboStore, and thus the source of my
shadow failures.  The question is:  Is my understanding of the way
TurboStore works correct?

Thanks,

Randall Davis