Hello,

Can anyone shed a light on whether to use or not to use DataExchange ?
Is it a mature product ?

My customer is currently testing it.
They see one problem with it - if databases go out of sync , then
re-synchronization takes too much time - more than 15 hours (16GB of data).
It's plain too long to use it in production. Are there workarounds?

Thanks in advance
Przem

We have several customers using it successfully.

I am intrigued by your customers experience -- why do the databases go
"out of sync"? Since the database is continually keeping track of
database changes on both side of the link, and since the database keeps
90 days of changes, as long as you initiate replication once every 80
days or so, then you shouldn't ever need to perform a Full Push
Replication -- a normal replication should cover all of the changes
that have been pending.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - July 19-22 ***
*** Chicago: Pervasive DataExchange Class - July 27-29 ***


Przem wrote:

Hello, thanks for a reply, a bit of delay...

My customer just wants to know how long will it take to bring back his
data from backup after server's crash.

Suppose you have a server, a 1-seat backup server and DataExchange
backup edition.

Then your main server dies. All data is gone. We have backup on
another server.
So you have to restore data from backup server and restore
DataExchange config , so that before people start working data is in
sync again.

Unless I'm mistaken, simple copying files with Explorer from backup
server to restored server won't do the trick. Or will it?

Thanks in advance
Przem

"Bill Bach" <billbach (AT) goldstarsoftware (DOT) com> wrote

With DataExchange, you configure the primary server to periodically
synchronize with the backup server. This sync process sends all
changes since the last sync process, so it only sends the changes --
not the entire file set. The most common interval for synchronization
is 3-5 minutes, although I do know of some sites that sync every one
minute. Personally, I'd rather see a 5-minute schedule or higher, but
much depends on the data, the risk of data loss, and that sort of
thing. This is a decision best left to the "business" folks.

When the primary server fails, the users all get kicked out of the
application. At some point, a decision is made to abandon the primary
server and switch to the backup server. All the users need to do is to
change the application to use the backup server, and restart their
application (with data that is current as of the last sync point). For
some apps, this is as simple as remapping a drive letter or two. Other
apps need changes to desktop icons. Others need INI or configuration
file changes. Others need registry changes. (Obviously, you'll want
to check with your app developer to determine how to point the app at a
different server.) Now, you are running in "failure mode", on the
backup server.

You can take your time and properly restore the primary server, getting
it back running with a full copy of the data as of the point of
failure, or even bring it up with a clean OS. Luckily, you can take
your time with this step & do it right.

Then, when you have a reasonable downtime window, you can do one of
three main things: 1) Bring all of the data back to the primary server
(via DX); 2) Bring all the data back to the primary via XCOPY and
manually clean up the DX environment; or 3) Leave the data on the
backup server, but call it the primary server now and redeploy DX in
the other direction (so that the second server becomes the primary
server now). There are a lot of symantics to consider when you
evaluate the options -- things that we cover in our DX training class
-- such as how much time has passed, how much confidence you have in
the "failed" primary server, and more.

As you suspect, there is a lot behind getting the failed system back
online and synchronizing again, but because you can do it carefully
during a downtime window, the impact of the fail-back can be minimized.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - July 19-22 ***
*** Chicago: Pervasive DataExchange Class - July 27-29 ***

Przem wrote:

Hello Bill,

Thank you for your detailed answer.

Good to know that firms use DX - with a success.
Good to hear there is option #2 ( Bring all the data back to the
primary via XCOPY and manually clean up the DX environment),
because:
- I have unrealistically short downtime deadline (say 2-3 hrs),
- They can't afford second full-blown server that can run for 35+
users
(they can but they say they can't). etc etc

I really appreciate your help
Thanks a lot
Przem