Error -1601

[mmas...@my-deja.com]

Hello,

I need some replication help with the partial replication feature on
Access 97 (Jet 3.5). Could you help me?

In my company, there are three distant sites without a WAN connection.
To share our customer data, we used normal replication. Replicas were
synchronized in the headquarters and zipped/distributed/returned by
email to the other two offices.

That was OK, but we wanted to minimize conflicts. So one day, we
converted main database to a regular one, redesigned conflictive tables
to have its index as a Replica Id field and remade all replicas. As we
expected, conflicts rarely arised. That was OK too.

My last improving action is to include partial replication feature. As
some data hasn't to be shared with offices, we implemented partial
replication (after converting our database to a regular one). We
created partial replicas and sent them to offices. Ther were som
problems but all seemed to be in its way.

Now, I have received the first replica to synchronize. I could
incorporate all new data to the main copy (synchronizing from copy to
main replica), but I could not finish to repopulate the copy. An
unexpected error occured (ERROR 3000 (-1601) with no messages). After
that, I hav tried it all: dropped the replica and recreate a new one,
but the error was there again.

So, nevertheless I have all data in the main replica, I cannot
regenerate that office replia.

What's wrong? Is there any other way to partialy share data without all
that complicated stuff?

Thanks in advance

Sent via Deja.com http://www.deja.com/
Before you buy.

[John Bouley]

You should not be copying replica's around. I don't know if this is causing
your errors but, it is a definite NO-NO. Even if it worked eventually your
replicas would run out of replica ID's. Every time you copy a replica and do
some sort of operation against it a new replica ID is generated. There is a
large number available but eventually you would run out!!
Your remote sites should be synchronizing via Indirect (dialup) or Internet.
I would seriously rethink your replication strategy if I were you.

Hope this helps,
John Bouley
<mmas...@my-deja.com> wrote in message news:8m70r9$4ad$1...@nnrp1.deja.com...

[mmas...@my-deja.com]

Thanks for your advice, but there are two problems:

1- We can't stablish a dial-up link with one of the sites (at present
day). This could be soved in the near future.
2- The most important thing. People at our distant offices hardly can
manage with technical problems (conflics and so), and enabling them to
do so would be a prolem for me.

So, I decided to control all the replicas management in the
headquarters (as far as there are only 3 replicas: the complete main
and the two partial ones).

Really, we are not copying replicas. We are moving them from
headquarters to offices and back. There are only two 'remote' replicas
and no new ones. When they are at remote sites, they are normaly used
(query, update and those usual actions). When they are back at
headquarters, they have a fixed path from where they are synchronized
with the complete main replica. After that, they are returned to
offices and so.

In article <OenwnM##$GA.197@cppssbbsa05>,

[Marcel Massana]

Sorry.

After some tests, nightmares and headaches, I've found the cause of
that error.

Some days ago I added a local table in the main design. That table had
a relation with a replicated table. After deleting that relation, all
began to work properly.

The conclusion is, I think, that there cannot exist relations between
local and replicated tables.

So, thanks

[Michael (michka) Kaplan]

(Yes, I am back. We will see for how long)

SORRY, but you are dead wrong here and you are trulu hurting your system.
Please see http://www.trigeminal.com/usenet/usenet009.asp for an
explanation. Summary: Jet replication is not designed for and will not
properly support disconnected users. PERIOD. End of discussion. It is very
dangerous to ignore this warning and also very stupid if a developer
knowingly does it; I used to make a great deal of money helping people
recover from the disasters it often caused until I decided that there were
less annoying ways to make money than to help people who do not listen.

THINK ABOUT IT. Read the posting at the URL above and decide if your client
or boss or whoever would decide they no longer wanted you working for them
if they found out the risk you were taking with their data.

--
MichKa

random junk of dubious value at the multilingual
http://www.trigeminal.com/ and a new book on
i18N in VB at http://www.trigeminal.com/michka.asp

<mmas...@my-deja.com> wrote in message news:8m8n15$cs5$1...@nnrp1.deja.com...

> Thanks for your advice, but there are two problems:
>
> 1- We can't stablish a dial-up link with one of the sites (at present
> day). This could be soved in the near future.
> 2- The most important thing. People at our distant offices hardly can
> manage with technical problems (conflics and so), and enabling them to
> do so would be a prolem for me.
>
> So, I decided to control all the replicas management in the
> headquarters (as far as there are only 3 replicas: the complete main
> and the two partial ones).
>
> Really, we are not copying replicas. We are moving them from
> headquarters to offices and back. There are only two 'remote' replicas
> and no new ones. When they are at remote sites, they are normaly used
> (query, update and those usual actions). When they are back at
> headquarters, they have a fixed path from where they are synchronized
> with the complete main replica. After that, they are returned to
> offices and so.
>

[Michael (michka) Kaplan]

(Yes, I am back. We will see for how long)

Look,

FIRST OF ALL, relationships that are enforced cannot be made between
replicated and non-replicated tables, and NON-ENFORCED rels serve no purpose
in any Jet database, whatsoever.

SECOND OF ALL, John was right, and what you are doing here is very stupid.
See my other post in this thread that explains why.

--
MichKa

random junk of dubious value at the multilingual
http://www.trigeminal.com/ and a new book on
i18N in VB at http://www.trigeminal.com/michka.asp

"Marcel Massana" <mmas...@my-deja.com> wrote in message
news:8m9dvr$t0p$1...@nnrp1.deja.com...

> Sorry.
>
> After some tests, nightmares and headaches, I've found the cause of
> that error.
>
> Some days ago I added a local table in the main design. That table had
> a relation with a replicated table. After deleting that relation, all
> began to work properly.
>
> The conclusion is, I think, that there cannot exist relations between
> local and replicated tables.
>
> So, thanks
>

[Marcel Massana]

Thanks for your answer, I like yo know the reasons why I'm wrong.

Nevetheless, I would like to read that explanation in english (if it
exists), because that bad translation is hard to read for me.

Paralelly, what do you suggest? How can be partially shared our
database without the replication feature with a site that only has an
email connection with headquarters?

Thanks in advance.

PS: I've read some of the posts in this forum and articles elsewhere
and haven't found a solution.

In article <esHZVAQ$$GA.85@cppssbbsa04>,
"Michael \(michka\) Kaplan"

<forme...@spamfree.trigeminal.nospam.com> wrote:
>
> (Yes, I am back. We will see for how long)
>

> SORRY, but you are dead wrong here and you are trulu hurting your
system.
> Please see http://www.trigeminal.com/usenet/usenet009.asp for an
> explanation. Summary: Jet replication is not designed for and will not
> properly support disconnected users. PERIOD. End of discussion. It is
very
> dangerous to ignore this warning and also very stupid if a developer
> knowingly does it; I used to make a great deal of money helping people
> recover from the disasters it often caused until I decided that there
were
> less annoying ways to make money than to help people who do not
listen.
>
> THINK ABOUT IT. Read the posting at the URL above and decide if your
client
> or boss or whoever would decide they no longer wanted you working for
them
> if they found out the risk you were taking with their data.
>

> --
> MichKa
>
> random junk of dubious value at the multilingual
> http://www.trigeminal.com/ and a new book on
> i18N in VB at http://www.trigeminal.com/michka.asp
>

> <mmas...@my-deja.com> wrote in message news:8m8n15$cs5

$1...@nnrp1.deja.com...
> > Thanks for your advice, but there are two problems:
> >
> > 1- We can't stablish a dial-up link with one of the sites (at
present
> > day). This could be soved in the near future.
> > 2- The most important thing. People at our distant offices hardly
can
> > manage with technical problems (conflics and so), and enabling them
to
> > do so would be a prolem for me.
> >
> > So, I decided to control all the replicas management in the
> > headquarters (as far as there are only 3 replicas: the complete main
> > and the two partial ones).
> >
> > Really, we are not copying replicas. We are moving them from
> > headquarters to offices and back. There are only two 'remote'
replicas
> > and no new ones. When they are at remote sites, they are normaly
used
> > (query, update and those usual actions). When they are back at
> > headquarters, they have a fixed path from where they are
synchronized
> > with the complete main replica. After that, they are returned to
> > offices and so.
> >

[Marcel Massana]

Thanks for your answer, I really appreciate to know the reasons why I'm