Losing record with replication scheme

[SAP2]

Scenario:
System data changes at least once per week. Multi users can change data any
number of times.
I have a Design Master(DM) that is a BE that accepts the data (table)
changes which I control.
There is a Hub replica of the DM on the local server.
There is a Server replica of the Hub with FE (doesn't get used much, too slow)
Each user has their own replica (Rn) of the Hub on each laptop (8) and FE
linked to the respective replica.

The logic I used when this was set up was that each user could take their FE
with them (they can choose to connect or not) and then sync directly (in both
directions)with the Hub when in the office. Basically they could work
independently of the server then downlad their updates and get new data when
they connected.

What I think is happening is that when I run the updated system data I have
to change tables (Data) in the DM then sync with Hub. Another user may have
made changes to an existing entry (prior to the system sync) then sync with
the Hub (bi-directinally) and lose the data that they had entered. No
conflicts are logged that I can find.

I am looking for suggestions on how to best fit my needs. I realize that
this may not be the best way and am open to alternatives. The basic result
needs to be that the user can share updated records with the Hub AND receive
new (added) information at any time without losing anything in translation.

Thank you in advance.

 

[SAP2]

Ok. I did a test and found that when I update the data in the DM I delete a
table then import the new one into the database and then make it replicable.
I guess this resets the table in comparison to the other replicas and that is
why the data is getting overidden.

So my question would be how to add the new data (which the users need) in
the DM without creating a new table or interrupting the replication link to
the original table?

 

[David W. Fenton]

First off, you should never use your Design Master for production
data entry. The DM should be squirrelled away somewhere safe and
synched with the replica set on a regular schedule to make sure it
doesn't expire (the default retention period is 1000 days, so once a
month would be quite sufficient).

Ok. I did a test and found that when I update the data in the DM
I delete a table then import the new one into the database and
then make it replicable. I guess this resets the table in
comparison to the other replicas and that is why the data is
getting overidden.

This is not a proper way to do things in a replicated database.

So my question would be how to add the new data (which the users
need) in the DM without creating a new table or interrupting the
replication link to the original table?

Well, that depends on a number of factors. Are the users updating
the records that you were deleting? If so, are you replacing those
records with new records that serve the same purpose? If so, then
you need to stop deleting the data and instead, update the records.

It's not at all clear to me what your doing, but I've never done
anything like what I understand you to be describing in any app,
replicated or not. Well, I do use temporary tables, but temp tables
never should be replicated (because it's temporary data).

Tell us more about what you're trying to accomplish and it should be
easier to offer a solution to your problem.

 

[Visitbazaar Info]

Visitbazaar.com is a secure online shopping mall where you can shop over 200
stores and save up to 60% and more with coupons, deals and discounts. Since
October of 2007, we have helped many customers save money on products &
services ranging from arts and crafts to web services. At Visitbazaar.com,
we are strongly committed to keeping our online mall a safe place to shop
at, and to help our customers save money on a wide selection of products &
services.

My Window is a browser application which increases the internet browsing
speed by applying various compression techniques and protocol optimization.
Reduces the upload and download time in FTP. To switch on MyWindow feature,
log on Visitbazaar.com now.

Regards
Visitbazaar Info

 

[SAP2]

David,
Thanks for your reply to my inquiry. I hope these responses will help fill
in the gaps.

First off, you should never use your Design Master for production
data entry. The DM should be squirrelled away somewhere safe and
synched with the replica set on a regular schedule to make sure it
doesn't expire (the default retention period is 1000 days, so once a
month would be quite sufficient).

I have seen you post this before in other threads. At the time I was sort
of under the gun to get the DB out and it was the only solution I could think
of at the time.

This is not a proper way to do things in a replicated database.

Understood. I began working on a way to update the existing tables instead
of deleting. Deleting just was too easy.

Well, that depends on a number of factors. Are the users updating
the records that you were deleting? If so, are you replacing those
records with new records that serve the same purpose? If so, then
you need to stop deleting the data and instead, update the records.

Yes. Yes. OK.
It seems simple enough. Cannot understand why I could not see it.

It's not at all clear to me what your doing, but I've never done
anything like what I understand you to be describing in any app,
replicated or not. Well, I do use temporary tables, but temp tables
never should be replicated (because it's temporary data).

Tell us more about what you're trying to accomplish and it should be
easier to offer a solution to your problem.

I am trying to utilize the data we collect outside of the internal network
and integrate it into the system data. Example:

We have a list of Purchase Orders (PO's) that carry all the relevant info
with that PO#. There are about 5,000 records that are updated periodically.
My team goes to our vendors and collects information relating to the PO's and
inputs that info into access using my DB. The info is reported along with
the usual stuff that is in the system already.

Therefore the PO information can be updated from the system link and the
information added by the DB.

Should I put the update/append queries in the Hub? What about automation?
I cannot put modules or macros into a replicated DB.

I currently have added all of my relevant tables (local) and queries (local)
to the Hub and trying it that way.

Thanks again.

 

[David W. Fenton]

I am trying to utilize the data we collect outside of the internal
network and integrate it into the system data. Example:

We have a list of Purchase Orders (PO's) that carry all the
relevant info with that PO#. There are about 5,000 records that
are updated periodically. My team goes to our vendors and
collects information relating to the PO's and inputs that info
into access using my DB. The info is reported along with the
usual stuff that is in the system already.

Therefore the PO information can be updated from the system link
and the information added by the DB.

Should I put the update/append queries in the Hub? What about
automation? I cannot put modules or macros into a replicated DB.

They should be in your front end. They should operate on data in the
back end replica's tables. Then whatever changes you make will synch
with the other replicas.

I currently have added all of my relevant tables (local) and
queries (local) to the Hub and trying it that way.

I'm having trouble figuring out what the issue is. If you update the
records in one replica and then synch with the other replicas, the
edits will be in the other replicas then. That is, if you process a
group of records on a central replica, the other replicas will have
those updates as soon as they synch with that central replica (or
any replica that has synched with the central replica). That's the
whole point of replication!

 

[SAP2]

I am trying to utilize the data we collect outside of the internal

They should be in your front end. They should operate on data in the
back end replica's tables. Then whatever changes you make will synch
with the other replicas.

Some of the updates take far too long to be put on the users' FE. They need
to be behind the scenes so the users just get the updates and do not have to
wait for the queries to run.

I'm having trouble figuring out what the issue is. If you update the
records in one replica and then synch with the other replicas, the
edits will be in the other replicas then. That is, if you process a
group of records on a central replica, the other replicas will have
those updates as soon as they synch with that central replica (or
any replica that has synched with the central replica). That's the
whole point of replication!

The original issue was with losing data when synching but you have helped me
resolve this by showing me that I should not delete replicated tables (just
update/append). That is done in my mind.

The one thing I guess I am missing is (and perhaps my set up is incorrect)
how do all the updates take place without the user being affected (again time
to perfrom updates)?

 

[David W. Fenton]

Some of the updates take far too long to be put on the users' FE.
They need to be behind the scenes so the users just get the
updates and do not have to wait for the queries to run.

I'm not suggesting you *execute* the queries in the users' front
ends. You would execute that in *your* copy of the front end, to
update your local replica's data. Then you'd push out the updates to
the data via a synchronization.

You could have the queries/code for the update in any front end --
doesn't have to be in the one the users use.

The original issue was with losing data when synching but you have
helped me resolve this by showing me that I should not delete
replicated tables (just update/append). That is done in my mind.

The one thing I guess I am missing is (and perhaps my set up is
incorrect) how do all the updates take place without the user
being affected (again time to perfrom updates)?

You do the updates in one replica and then synch with the other
replicas. The only time involved for the users is the time it takes
to synch.

I think you have some confusion about replication, as this seems to
me to be blazingly obvious! Maybe I'm just not explaining it well.

 

[SAP2]

David,
Thank you very much for taking the time to review this with me. My whole
thinking was off on how to accomplish what I wanted. I will use my FE to
perform updates and sync with the DM to distribute to other replicas. Thank
you again.