Hi,

Thanks for you input.

For some reason I thought that DBCs contained some info about number of records (of tables) and things like that...I don't know why I thought that...but I had a look and I was obviously mistaken as some of our DBCs haven't been changed for months. So it is true that DBCs should not present a problem except for periodic changes to the DBC it self...thanks.

Take care,
Joe


>>>In VFP, I think you could solve the 24/7 problem with an audit feature: every change in every table triggers an addition to an additional table.
>>
>>I think I would still see problems with the DBCs in some cases.
>
>Well, what I was thinking was something like this: every change, be it adding, modifying or deleting a record, is APPENDED to the audit table. Then, if your last backup copied all records up to 10,000 (in the audit table), your next backup can copy records starting at 10,001. The changes, recorded in the audit table, can then be re-applied to an off-line copy of the original DBFs.
>
>I think the problems with the DBCs would affect commands which modify the structure - but not the backups themselves. Changing the structure is a separate challenge - and I doubt you can do it (without C/S) with a 24/7 system.
>
>>>Or change to C/S. Servers like Oracle have built-in support for a "hot" backup.
>>
>>Arggghhh...I fear this might be the only real solution.
>
>And Oracle, AFAIK, allows you to add fields to a table while people access the table.
>
>You would have other advantages, too. However, I understand the "Arggghhh..." part very well; I wouldn't like to do a major re-design to my current system. Which would be required, were I to change to C/S.
>
>Hilmar.