Replication/Synchronisation failure

[Dumbo Liz]

Hi
I hold a Design Master for development and synchronise this weekly
with my colleague who enters data and runs reports. This has worked
well for the last 3 months. (He e-mails me a copy and I'm scrupulous
about keeping files in the right place!)
This week Synchronisation failed because "it is not a replicable
database".
I tried compact and repair on the Replica. This produced Conflict
Tables for both my Tables and MSys_Access_Obj ects_Tables. When I tried
to resolve these I was unable to View because "no tables" !!!
From the Replica I do not have the option to make it a Design Master
(the only option available is "Make Replica")
I haven't actually changed the Design Master since this Replica was
made. But I don't want to lose all the data my colleague has keyed in.
And I'm worried about why this has happened.
Can anyone help? I'm off to cook Christmas Eve dinner for the family,
so there's no rush.
Thank you, and a Merry Christmas to all
Liz

[cindy Le]

is this a database that was converted from access97?
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[David W. Fenton]

du**********@ya hoo.co.uk (Dumbo Liz) wrote in
<17************ **************@ posting.google. com>:

I hold a Design Master for development and synchronise this weekly
with my colleague who enters data and runs reports. This has
worked well for the last 3 months. (He e-mails me a copy and I'm
scrupulous about keeping files in the right place!)
You can't email replicas because as soon as you open it, it will be
assigned a new ReplicaID, and then when you copy over top of it,
you'll have a dead replica.
This week Synchronisation failed because "it is not a replicable
database".
I tried compact and repair on the Replica. This produced Conflict
Tables for both my Tables and MSys_Access_Obj ects_Tables. When I
tried to resolve these I was unable to View because "no tables"
!!! From the Replica I do not have the option to make it a Design
Master (the only option available is "Make Replica")
I haven't actually changed the Design Master since this Replica
was made. But I don't want to lose all the data my colleague has
keyed in. And I'm worried about why this has happened.

Is this data only in this replicated MDB or does it include forms
and reports? If the latter, then you've got a bad design --
replication works reliably only on pure Jet objects (tables and
queries), not on Access objects. Corruption and complete project
and data loss often occurs when people don't split data and
replicate the whole thing.

A few other points:

1. the design master should never be used for anything but making
design changes. That means you should synch it only occasionally
and never, ever use it for production work.

2. it's best to use a "replica farm" (see trigeminal.com for an
explanation), because then any particular replica is disposable,
because there are always other replicas with the same data in them.

3. never copy or move replicas by any method that does not involve
Jet-specific methods. This means: not file copies, no emailing, no
floppy disks. If you break this rule, you may eventually lose all
your data to replication errors. It also means that once
replication errors appear, you can never be certain that your
replicas are fully synching.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Larry Linson]

"David W. Fenton" wrote

. . . It also means that once replication
errors appear, you can never be certain
that your replicas are fully synching.

Well, I have always said, "Replicatio n isn't for the faint of heart."

[David W. Fenton]

bo*****@localho st.not (Larry Linson) wrote in
<KV************ ******@nwrddc01 .gnilink.net>:

"David W. Fenton" wrote

. . . It also means that once replication
errors appear, you can never be certain
that your replicas are fully synching.

Well, I have always said, "Replicatio n isn't for the faint of
heart."

Nowadays with cheap and fast Internet access and Windows Terminal
Server as part of Win2K (much less expensive and difficult than in
the old days, before Win2K), I don't see much call for Jet
replication in a lot of scenarios any more. The only scenario for
using Jet repllication that still makes some sense is for laptop
users who cannot connect to the Internet when away from the office.

All the other scenarios that Jet replication was good for have been
"obsoleted" by WTS, in my opinion.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Dumbo Liz]

Hello David
Thank you for your reply. I had no idea that Rep/Sync was so unstable.
I will certainly look at the replica farm idea, but I am clearly in a
lot of trouble with this one. (Windows XP/Office 2002)
I'm not an IT specialist but found Access useful for my job. When I
gave up employment in the summer I was invited to write a membership
database for a charity I'm involved with. Initially I thought I would
write the data storage (tables and forms) and they would do all the
interrogation (queries/reports etc). But like Topsy it's grown and
grown and I've been on a steep learning curve into the intricacies of
Access (working on my own from a manual!). The Charity doesn't have a
permanent office so the database moves from place to place and they
are not reliably or speedily on the Internet, they don't want this
database on the web. However, they do need to enter data regularly and
they ask for more reports as they get to understand the capabilities.
So, Rep/Sync seemed the answer to my prayers, but it does include
queries and reports.
So I'm left with two problesm:-
1) Is there any easy way to recover? The only way I can think of is to
export the data, rewrite the database and import the data back to a
"normal" database. (Then use copy)
2) So far I've only done a small part of the project, the biggest bit
starts in a couple of weeks. How can I continue to develop while the
Charity continues to add data? Is copy the only way?
I realise these are big (and possibly dumb) questions, and I am very
grateful for your help.
Liz

[David W. Fenton]

du**********@ya hoo.co.uk (Dumbo Liz) wrote in
<17************ **************@ posting.google. com>:

Thank you for your reply. I had no idea that Rep/Sync was so
unstable. . . .
Well, it's *not* unstable. You just have to use it the way it was
designed to be used, which is exclusively over network connections.
. . . I will certainly look at the replica farm idea, but I am
clearly in a lot of trouble with this one. (Windows XP/Office
2002) I'm not an IT specialist but found Access useful for my job.
Access is a mix of simple-to-use and very advanced features that
require caution and a great deal of understanding to use
successfully. Microsoft has never quite managed to serve well the
users of both levels, as your replication fiasco demonstrates (you
stumbled into something complex that wasn't presented that way).
When I gave up employment in the summer I was invited to write a
membership database for a charity I'm involved with. Initially I
thought I would write the data storage (tables and forms) and they
would do all the interrogation (queries/reports etc). But like
Topsy it's grown and grown and I've been on a steep learning curve
into the intricacies of Access (working on my own from a manual!).
The Charity doesn't have a permanent office so the database moves
from place to place and they are not reliably or speedily on the
Internet, they don't want this database on the web. However, they
do need to enter data regularly and they ask for more reports as
they get to understand the capabilities. So, Rep/Sync seemed the
answer to my prayers, but it does include queries and reports.
Are the data tables in one MDB and the forms/reports, etc. in
another one? If not, that's what you need to do first. Recover the
data, and then figure out how to recover the Access objects after
that.
So I'm left with two problesm:-
1) Is there any easy way to recover? The only way I can think of
is to export the data, rewrite the database and import the data
back to a "normal" database. (Then use copy)
Well, it sounds like your situation is one-way in terms of data
editing (you don't edit the data, right?), so the *real* data is
safe at the client's.

As to the Access objects, the client has a good replica with forms
and reports from before the synch, right?
2) So far I've only done a small part of the project, the biggest
bit starts in a couple of weeks. How can I continue to develop
while the Charity continues to add data? Is copy the only way?
I realise these are big (and possibly dumb) questions, and I am
very grateful for your help.

Well, I don't see any reason why you need replication at all:

1. unreplicate the client copy of the database using the
unreplication tools available on http://www.trigeminal.com .

2. split the application into data MDB (data tables only), and
application MDB (forms, reports, etc., with links to the data MDB).

3. for reporting purposes, have the client send you their data MDB,
write the reports in your application MDB and send them back only
the application MDB.

The client will either need to learn how to relink tables or you'll
need to set it up for them to do it automatically (if possible) or
to prompt them for the back end location the first time they open
the new application MDB on their network.

Splitting the database is simply basic standard Access application
design -- it's in the help files, even, and has ben since at least
Access 2.

If you have something that needs to be recovered from the corrupted
repllica, then perhaps pksolutions.com can help, but replication
issues are not the same as normal data corruption issues, so the
chances of recovery are, perhaps, not as high as normal.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Dumbo Liz]

Hi David
This is an ace reply, thank you. I'm tied up with family Christmas
celebrations at the moment (although I'd prefer to be working on my
database - is that sad?!). I'll let you know how I get on in a day or
so.
Happy New Year!
Liz

[Dumbo Liz]

Hello David
When I use the UnReplicate package I lose the Queries in my database
(but not reports or tables). Can you help with this at all, please?
regards, Liz

[David W. Fenton]

du**********@ya hoo.co.uk (Dumbo Liz) wrote in
<17************ **************@ posting.google. com>:

When I use the UnReplicate package I lose the Queries in my
database (but not reports or tables). Can you help with this at
all, please? regards, Liz

That's odd. Can't you just import them from replica into your new,
unreplicated MDB? Queries have no replication properties that will
survive the import into an unreplicated MDB, so far as I am aware.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc