>>We may run 24/7 in the near future and there is one issue that I know we need to resolve. Currently to refresh a Development or Testing environment we will simply copy the data files from Production. We have had problems on occasion with this because during the copy process a CDX or FPT may have been already copied, then a different large file gets copied, and in the meantime the DBF changes due to editing. The CDX, FPT and DBF are now out of sync. At this moment we can simply do it at night or over the weekend when the system is likely not active, but how to do this when it is?

Snip

>However... I've noticed that filetostr() reads anything, regardless of it being in open elsewhere, and is extremely fast. So you may try putting all three of dbf, cdx and fpt into three strings, one after another, and then write them out. Depending on the size of your files, maybe even this may not be fast enough, and a replication thingy may be a better way of doing this - select * from prodfile p1 into cursor tmp where p1.pk not in (select pk from devfile), and then select devfile and append from dbf("tmp"). That's for new records, but if you have a timestamp of last edit in each record of each table, you may just use that as an additional clause or a union. I'm doing something like that to update remote SQL from local dbfs, and it works like it should.

This is more intended for Renoir than you Dragan, but your text above puts things nicely into context.

Is there any reason the FileToStr()'s couln't be wrapped in an FLock() - at the moment I rely on a SQL Select relying on a DateTime stamp to pull out Updated / Inserted rows. This is very quick and I'm not sure it's worth investigating the FileToStr() alternative.