filepro and saving data

[Fairlight]

Yo, homey, in case you don' be listenin', Richard D. Williams done said:
> 
> What is the limitation/downside of doing a back-up, rsync, or any other 
> attempt to reduce the data lose window between back-ups on an active 
> filepro system with remote users?

If a file is currently being used, there's an increasing chance as the
file is more heavily used that rsync will grab diffs for something that's
only half-modified.  It's a race condition that filePro makes no allowance
for preventing, to the best of my knowledge.

In short, there's the potential that you could wipe a slightly older (but
good) backup copy in favour of a more recent but corrupt one.  That
potential shrinks as a table is less used, and goes away when it's not
being used at all.

> Are there any suggestions on how to maintain to duplicate linked filepro 
> system?

Well, a year or two ago I proposed a transactional system that would even
allow multiple web servers to coordinate with a central data server to keep
everyone with the most current data at a fairly atomic rate (every 5
minutes or so).  I was planning on designing something around the concept
of RSS, but scaling it back to only what would be needed for the task.

As with the generic XML importer module I wanted to start writing within
the last month, I talked to a few people, and while everyone seems to think
they'd both be useful, concensus is that nobody in the community would
bother paying enough for either to make it worth my time to code them.
I'll say one thing for this community--it know how to kill good projects.

Ironic, really--one person told me that the XML importer they wouldn't pay
more than $500 for.  Another said it's probably worth thousands if the user
(or developer) needed it badly enough, but it wasn't something you could
stick a stock price on.  Add to that the experiences I've had where you
might sell one copy in the first six months and it -might- pick up after
that (or worse--someone asks for something Very Specific, you write it, and
even that one person never bothers getting it)...well, I did the math on
selling one copy at $995 as opposed to the minimum hours I figured it would
take me.  I also decided that it makes zero sense to code for that rate
when I can do Real Work for much more.

So no, the RSS solution never came to be written.  But that's where I'd
look as far as borrowing ideas on how to keep multiple systems sync'd
in a transactional fashion.  Technically, it could also be done via CGI
as well.  Either transport/direction would work.  The question is, how
expensive is it to implement.  Since there are no mechanisms in filePro
for doing this, you have to put -something- new in your processing.  Even
given a module that can handle add/update/delete, you'll still have to call
the appropriate functions at the right times, which means it could -not-
just be a drop-in module, but would be a module you'd have to alter your
processing for any tables wishing to use it.  Not horribly elegant.

By the time I got done -thinking- about how this could be made to work
halfway gracefully, I realised I'd exceeded more than I was likely to ever
make on it, so I dropped it as a waste of time.

Happens a lot around here.

There's no -easy- way to do this as an atomic, transactional system, AFAIK.

mark->