I have a need for a P2P client to be able to grab a copy of the
server's database.

With DBISAM I simply wiped the client's data folder then copied over
the server's data folder contents.  Not huge amounts of data.

With EDB is that still a reasonable option (including the Config
files) or are there better and or safer ways?  Would copying a .Lck
file be a bad thing?

It seems to me that while the client is connected to the server's
Config it will only know about the server's stores and not its own
local ones (and they would all have to be in UNC format) so a
Backup/Restore operation may not be an option?

--

Malcolm,

<< I have a need for a P2P client to be able to grab a copy of the server's
database. >>

Just to clarify: in this case "server" means file server, not EDB Server,
correct ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Malcolm,
>
> << I have a need for a P2P client to be able to grab a copy of the
> server's database. >>
>
> Just to clarify: in this case "server" means file server, not EDB
> Server, correct ?

Yes, I think so.    My app has a local database for stand-alone,
but several instances (clients) can run on a LAN, all connecting to
the database of a particular instance (becoming the 'server').

I have had a play while you were bug fixing.  I seem to be able to
get away with *not* copying the file server EDBConfig.* files back to
the client's local database.  But if I want to avoid the 'Infernal'
build number error I do have to copy back the EDBDatabase.* files and
then alter the database LOCAL PATH before opening.

I do not allow instances with differing software version numbers to
share a database so the DB structures should be identical.

But there may be a gotcha I have overlooked .. or a much better way(?)

--

Malcolm,

<< Yes, I think so.    My app has a local database for stand-alone, but
several instances (clients) can run on a LAN, all connecting to the database
of a particular instance (becoming the 'server'). >>

Yes, that's the file-server.

<< I have had a play while you were bug fixing.  I seem to be able to get
away with *not* copying the file server EDBConfig.* files back to the
client's local database.  But if I want to avoid the 'Infernal' build number
error I do have to copy back the EDBDatabase.* files and then alter the
database LOCAL PATH before opening. >>

Yes, that's correct.  However, is the source database being used when the
copying occurs ?  If so, then there is the distinct possibility that you
could get an out-of-synch database by doing a straight file copy, in which
case you'll want to use the backup/restore method instead.  The good thing
is that you can make this work with a file-sharing arrangement, and can even
make it work using the same global configuration file.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>
> Yes, that's correct.  However, is the source database being used
> when the copying occurs ?  If so, then there is the distinct
> possibility that you could get an out-of-synch database by doing a
> straight file copy, in which case you'll want to use the
> backup/restore method instead.  The good thing is that you can make
> this work with a file-sharing arrangement, and can even make it
> work using the same global configuration file.

The copy would normally be done at a quiet moment.  But if
Backup/Restore can be made to work across P2P, I'm interested.  OK, I
will read the Manual again (again!).  

--