email replicas?

[Tim Cali]

If I create a 2 replicas on my machine, can I email them to two different
users, let them add their data as needed, then receive the MDBs back via
email and synchronize them on my machine?

 

[Paul Overway]

Maybe. It depends on whether changes need to go back to the 2 users and how
often you plan on doing it. Nevertheless, this really isn't a good way to
implement replication and could lead to errors and corruption of your
replica(s). See http://www.trigeminal.com/resources.asp?1033 for more info
on replication and the microsoft.public.access.replication NG.

 

[Tim Cali]

Thanks. This is a one-off situation. It is important that the primary DB (is
this the design master?) will always receive, and never need to update the
secondary DB.

I have read the FAQ
(http://support.microsoft.com/default.aspx?scid=/support/access/content/repl
/replfaq.asp),
question #43, which states:
-----------------------
Can I replicate through e-mail instead of over a network or dialup
connection?
No. This feature is not supported at this time.
------------------------

What does that mean?

My situation is this:
Client is using a split DB on a laptop. They would like to create another
copy on another laptop for faster data entry. I, being in another city than
they, would like them to email me the backend. I will then replicate it,
email them back *both* backends. They will relink each respectively on 2
laptops. When they are done with data entry, they will email me both
backends, and I will synchronize them.

Is this doable?

 

[Tim Cali]

Just to clarify,

It is important that the primary DB (is
this the design master?) will always receive, and never need to update the
secondary DB.

The secondary DB's data is what needs to be imported into the primary. I
don't really care if changes are propagated to the secondary one, which I
guess they will be upon synchronization. That's fine.

 

[Michael \(michka\) Kaplan [MS]]

You cannot do this if you want a robust solution. See

http://trigeminal.com/usenet/usenet009.asp

for more informaton on why.

 

[Tim Cali]

Very good article. I am not looking for a robust solution, however, but
rather a "one-off" solution. If I cannot (or *should not*) use replication,
how may I achieve the goal?

You cannot do this if you want a robust solution. See

http://trigeminal.com/usenet/usenet009.asp

for more informaton on why.


--
MichKa [MS]

This posting is provided "AS IS" with
no warranties, and confers no rights.

Just to clarify,


The secondary DB's data is what needs to be imported into the primary. I
don't really care if changes are propagated to the secondary one, which I
guess they will be upon synchronization. That's fine.




DB
(is

(http://support.microsoft.com/default.aspx?scid=/support/access/content/repl

way back
via

 

[Paul Overway]

Given your description so far, I'm not sure that replication is even
necessary. You could probably just import the data from the 2 databases by
making sure that primary keys do not collide. If you're using autonumber
for PKs, set them to be random. Or use a multi part PK with one part being
a SiteID.

If this is a one time event, you'd probably be safe to replicate...but bear
in mind the warnings you've been given about illegal moves. You haven't
made it very clear about what your goal is though. Are you
sending/receiving the database once, and then synchronizing...never to do
again? Or are you sending the database and receiving it multiple
times...and synchronizing each time received? If the latter, replication
through email is not a good solution....follow the replication white paper
and implement a proper replication topography....or consider revising your
database so that PK collisions do not occur.

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com

Very good article. I am not looking for a robust solution, however, but
rather a "one-off" solution. If I cannot (or *should not*) use replication,
how may I achieve the goal?

You cannot do this if you want a robust solution. See

http://trigeminal.com/usenet/usenet009.asp

for more informaton on why.


--
MichKa [MS]

This posting is provided "AS IS" with
no warranties, and confers no rights.

Just to clarify,

It is important that the primary DB (is
this the design master?) will always receive, and never need to

update
the

secondary DB.

The secondary DB's data is what needs to be imported into the primary. I
don't really care if changes are propagated to the secondary one,

which

I

primary

DB update
the

(http://support.microsoft.com/default.aspx?scid=/support/access/content/repl on

2 users
and good
way

 

[Tim Cali]

Hi Paul:

If this is a one time event, you'd probably be safe to replicate...but bear
in mind the warnings you've been given about illegal moves. You haven't
made it very clear about what your goal is though. Are you

Client is using one unreplicated split DB, one BE and one FE. The called one
day and said "Data entry is taking longer than expected. Can we put a copy
of the DB on another laptop, so we can get somebody else on this project who
can help us enter data, so that we can finish data entry twice as fast?"
(This is a research-gathering DB...after all data is entered, it will
undergo further analysis, but the data entry part will be done). The data
being entered is survey information, so it is easy to ensure no duplication
on data entry (e.g. you enter this stack of surveys, and I enter that one).

I am in one city. They are in another city, and their DB is over there. We
share data via email only. They would email me their BE to-date, I would
make any changes as needed, and email them back whatever is required with
instructions on how to set up the second DB.

I believe this is a one-off event, in that the cycle I describe in the
paragraph above would only happen *once*, and after data entry is complete,
I would receive both BEs and synchronize/merge them into one final DB for
the further analysis. However, it is possible that they may want more than 2
DBs. The may find the second DB so useful that they allocate another person
to help with data entry, in which case they end up with THREE DBs. This is
possible.

Anyway, at the end of this, I believe that the easiest solution will be to
implement a multi-part, or random, PK like you suggest. I appreciate your
feedback...it has been very helpful. If you have any additional ideas, I am
all ears.

Best regards,
Tim

Given your description so far, I'm not sure that replication is even
necessary. You could probably just import the data from the 2 databases by
making sure that primary keys do not collide. If you're using autonumber
for PKs, set them to be random. Or use a multi part PK with one part being
a SiteID.

If this is a one time event, you'd probably be safe to replicate...but bear
in mind the warnings you've been given about illegal moves. You haven't
made it very clear about what your goal is though. Are you
sending/receiving the database once, and then synchronizing...never to do
again? Or are you sending the database and receiving it multiple
times...and synchronizing each time received? If the latter, replication
through email is not a good solution....follow the replication white paper
and implement a proper replication topography....or consider revising your
database so that PK collisions do not occur.

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com

Very good article. I am not looking for a robust solution, however, but
rather a "one-off" solution. If I cannot (or *should not*) use replication,
how may I achieve the goal?

You cannot do this if you want a robust solution. See

http://trigeminal.com/usenet/usenet009.asp

for more informaton on why.


--
MichKa [MS]

This posting is provided "AS IS" with
no warranties, and confers no rights.


Just to clarify,

It is important that the primary DB (is
this the design master?) will always receive, and never need to update
the
secondary DB.

The secondary DB's data is what needs to be imported into the

primary.

I which primary

(http://support.microsoft.com/default.aspx?scid=/support/access/content/repl

replicate
it,

respectively

on for
more MDBs
back

 

[Michael \(michka\) Kaplan [MS]]

Replication adds a *lot* of overhead and in a case where its a one-time
operation like this would be a really bad idea to go down that road.


--
MichKa [MS]

This posting is provided "AS IS" with
no warranties, and confers no rights.

Hi Paul:

If this is a one time event, you'd probably be safe to replicate...but bear
in mind the warnings you've been given about illegal moves. You haven't
made it very clear about what your goal is though. Are you

Client is using one unreplicated split DB, one BE and one FE. The called one
day and said "Data entry is taking longer than expected. Can we put a copy
of the DB on another laptop, so we can get somebody else on this project who
can help us enter data, so that we can finish data entry twice as fast?"
(This is a research-gathering DB...after all data is entered, it will
undergo further analysis, but the data entry part will be done). The data
being entered is survey information, so it is easy to ensure no duplication
on data entry (e.g. you enter this stack of surveys, and I enter that one).

I am in one city. They are in another city, and their DB is over there. We
share data via email only. They would email me their BE to-date, I would
make any changes as needed, and email them back whatever is required with
instructions on how to set up the second DB.

I believe this is a one-off event, in that the cycle I describe in the
paragraph above would only happen *once*, and after data entry is complete,
I would receive both BEs and synchronize/merge them into one final DB for
the further analysis. However, it is possible that they may want more than 2
DBs. The may find the second DB so useful that they allocate another person
to help with data entry, in which case they end up with THREE DBs. This is
possible.

Anyway, at the end of this, I believe that the easiest solution will be to
implement a multi-part, or random, PK like you suggest. I appreciate your
feedback...it has been very helpful. If you have any additional ideas, I am
all ears.

Best regards,
Tim

Given your description so far, I'm not sure that replication is even
necessary. You could probably just import the data from the 2 databases by
making sure that primary keys do not collide. If you're using autonumber
for PKs, set them to be random. Or use a multi part PK with one part being
a SiteID.

If this is a one time event, you'd probably be safe to replicate...but bear
in mind the warnings you've been given about illegal moves. You haven't
made it very clear about what your goal is though. Are you
sending/receiving the database once, and then synchronizing...never to do
again? Or are you sending the database and receiving it multiple
times...and synchronizing each time received? If the latter, replication
through email is not a good solution....follow the replication white paper
and implement a proper replication topography....or consider revising your
database so that PK collisions do not occur.

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com

Very good article. I am not looking for a robust solution, however, but
rather a "one-off" solution. If I cannot (or *should not*) use replication,
how may I achieve the goal?


message You cannot do this if you want a robust solution. See

http://trigeminal.com/usenet/usenet009.asp

for more informaton on why.


--
MichKa [MS]

This posting is provided "AS IS" with
no warranties, and confers no rights.


Just to clarify,

It is important that the primary DB (is
this the design master?) will always receive, and never need to update
the
secondary DB.

The secondary DB's data is what needs to be imported into the

primary.

I
don't really care if changes are propagated to the secondary one, which
I
guess they will be upon synchronization. That's fine.




Thanks. This is a one-off situation. It is important that the primary
DB
(is
this the design master?) will always receive, and never need to update
the
secondary DB.

I have read the FAQ

(http://support.microsoft.com/default.aspx?scid=/support/access/content/repl

another
city respectively

 

[Larry Linson]

Replication adds a *lot* of overhead and
in a case where its a one-time operation
like this would be a really bad idea to go
down that road.

Two comments:

I have been know to say, "If Michael Kaplan tells you a rooster can pull a
train, you can go buy your ticket."

And, from his posts and the posts of others, I long ago came to the
conclusion that "Replication is not for the faint of heart."

 

[Vitalijus J. Karalius]

Two comments:

I have been know to say, "If Michael Kaplan tells you a rooster can pull a
train, you can go buy your ticket."

And, from his posts and the posts of others, I long ago came to the
conclusion that "Replication is not for the faint of heart."

Yep, but until there's a decent alternative to Jet replication, you take
your Atenolol and press on....... :-\

 

[Arvin Meyer]

The key is the key <g>

Your implementation is one-way and they can easily replace their back-end
with yours. I believe that you can have as many computers as is practical
with all data moving one-way into a central location. As a matter of fact, I
implemented this in an Access 2.0 database before replication was even
possible.

My application took data from multiple vending machine readers and added it
to a central system, then summarized the data and deleted the detail
records. It processed between 80,000 and 100,000 records in less than an
hour. (usually about a half hour)

The key is the key.

Each machine needs to generate its own unique range of keys. I did that by
concatenating the reader (machine) name (or number) to an autoincrementing
number. It is important to point out that this violates 1NF in that the key
can be decomposed, but knowing that allowed me to assure through my code
that there never was a decomposition.

The first thing my code did was to run an update query that checked a column
that I used for the concatenation and added the reader number to the
autonumber column. Then it ran the series of other queries and reports. In
your case, it is even easier since you can build the concatenation as the
record is being created.

Remember. This only works one way. Existing records can only be edited at
the central location.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access

Hi Paul:

If this is a one time event, you'd probably be safe to replicate...but bear
in mind the warnings you've been given about illegal moves. You haven't
made it very clear about what your goal is though. Are you

Client is using one unreplicated split DB, one BE and one FE. The called one
day and said "Data entry is taking longer than expected. Can we put a copy
of the DB on another laptop, so we can get somebody else on this project who
can help us enter data, so that we can finish data entry twice as fast?"
(This is a research-gathering DB...after all data is entered, it will
undergo further analysis, but the data entry part will be done). The data
being entered is survey information, so it is easy to ensure no duplication
on data entry (e.g. you enter this stack of surveys, and I enter that one).

I am in one city. They are in another city, and their DB is over there. We
share data via email only. They would email me their BE to-date, I would
make any changes as needed, and email them back whatever is required with
instructions on how to set up the second DB.

I believe this is a one-off event, in that the cycle I describe in the
paragraph above would only happen *once*, and after data entry is complete,
I would receive both BEs and synchronize/merge them into one final DB for
the further analysis. However, it is possible that they may want more than 2
DBs. The may find the second DB so useful that they allocate another person
to help with data entry, in which case they end up with THREE DBs. This is
possible.

Anyway, at the end of this, I believe that the easiest solution will be to
implement a multi-part, or random, PK like you suggest. I appreciate your
feedback...it has been very helpful. If you have any additional ideas, I am
all ears.

Best regards,
Tim

Given your description so far, I'm not sure that replication is even
necessary. You could probably just import the data from the 2 databases by
making sure that primary keys do not collide. If you're using autonumber
for PKs, set them to be random. Or use a multi part PK with one part being
a SiteID.

If this is a one time event, you'd probably be safe to replicate...but bear
in mind the warnings you've been given about illegal moves. You haven't
made it very clear about what your goal is though. Are you
sending/receiving the database once, and then synchronizing...never to do
again? Or are you sending the database and receiving it multiple
times...and synchronizing each time received? If the latter, replication
through email is not a good solution....follow the replication white paper
and implement a proper replication topography....or consider revising your
database so that PK collisions do not occur.

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com

Very good article. I am not looking for a robust solution, however, but
rather a "one-off" solution. If I cannot (or *should not*) use replication,
how may I achieve the goal?


message You cannot do this if you want a robust solution. See

http://trigeminal.com/usenet/usenet009.asp

for more informaton on why.


--
MichKa [MS]

This posting is provided "AS IS" with
no warranties, and confers no rights.


Just to clarify,

It is important that the primary DB (is
this the design master?) will always receive, and never need to update
the
secondary DB.

The secondary DB's data is what needs to be imported into the

primary.

I
don't really care if changes are propagated to the secondary one, which
I
guess they will be upon synchronization. That's fine.




Thanks. This is a one-off situation. It is important that the primary
DB
(is
this the design master?) will always receive, and never need to update
the
secondary DB.

I have read the FAQ

(http://support.microsoft.com/default.aspx?scid=/support/access/content/repl

another
city respectively