Partially Disconnected Databases

[campbell_canuck]

I'm hoping to get a little advice.

I currently have a repository db that is located on a server. There
are a number of client databases that have their own interfaces (forms,
reports, queries) but use the repository db for storing data.

There is a new requirement for some users to be able to upload limited
and specific information to a laptop (or tablet), take it into a remote
(ie disconnected) environment, and update the information. On
returning to the office (and connecting to the network, either wireless
or with a network cable), the users need to be able to update the
repository db with the information they have entered in the remote
environment.

I've been instructed that Access is what the application MUST use.

So this is what I'm thinking of doing:

Each laptop would have a small db of its own. This would contain the
information the user requires in the field.

There would be 2 different Access applications on the laptop.

One would work with the data on the laptop and allow them to update the
information as required. This would not require a link to the
repository db.

The second application would use linked tables from the repository db
to "synch" the data. This would be a manually initiated process but
that's ok. This would involve queries to determine what data needed to
be updated back to the repository and what new data would be pulled
from it.

I've looked into replication but the addition of GUIDs and the
limitations imposed on the auto-number fields would make it a less than
desireable option.

Any advice?

[Lyle Fairfield]

"campbell_canuck" <ch*******@hotmail.com> wrote in
news:11**********************@v46g2000cwv.googlegr oups.com:

I'm hoping to get a little advice.

I currently have a repository db that is located on a server. There
are a number of client databases that have their own interfaces (forms,
reports, queries) but use the repository db for storing data.

There is a new requirement for some users to be able to upload limited
and specific information to a laptop (or tablet), take it into a remote
(ie disconnected) environment, and update the information. On
returning to the office (and connecting to the network, either wireless
or with a network cable), the users need to be able to update the
repository db with the information they have entered in the remote
environment.

I've been instructed that Access is what the application MUST use.

So this is what I'm thinking of doing:

Each laptop would have a small db of its own. This would contain the
information the user requires in the field.

There would be 2 different Access applications on the laptop.

One would work with the data on the laptop and allow them to update the
information as required. This would not require a link to the
repository db.

The second application would use linked tables from the repository db
to "synch" the data. This would be a manually initiated process but
that's ok. This would involve queries to determine what data needed to
be updated back to the repository and what new data would be pulled
from it.

I've looked into replication but the addition of GUIDs and the
limitations imposed on the auto-number fields would make it a less than
desireable option.

Any advice?

If I were doing this and the small db were indeed small I would
investigate using ado recordsets and their save and load methods. There
is very little fuss or muss to this.
Problems are
a) it's better suited to flat files than to related tables;
b) it's unlikely (IMO) that anyone else would do it this way. After all,
why use a very few lines of code when two-hundred fifty will do?

--
Lyle Fairfield

[david epsom dot com dot au]

Looks ok to me.

Using directly linked tables, you will be limiting yourself
to real connections.

I've always used XLS files, because they can be mailed
and edited.

My only suggestion is that you include a lot of status
information in your tables. If you are using queries to
update the master tables, include as data the date/time,
computer name, query name, version number, user name
and anything else you can capture.

(david)
"campbell_canuck" <ch*******@hotmail.com> wrote in message
news:11**********************@v46g2000cwv.googlegr oups.com...

I'm hoping to get a little advice.

I currently have a repository db that is located on a server. There
are a number of client databases that have their own interfaces (forms,
reports, queries) but use the repository db for storing data.

There is a new requirement for some users to be able to upload limited
and specific information to a laptop (or tablet), take it into a remote
(ie disconnected) environment, and update the information. On
returning to the office (and connecting to the network, either wireless
or with a network cable), the users need to be able to update the
repository db with the information they have entered in the remote
environment.

I've been instructed that Access is what the application MUST use.

So this is what I'm thinking of doing:

Each laptop would have a small db of its own. This would contain the
information the user requires in the field.

There would be 2 different Access applications on the laptop.

One would work with the data on the laptop and allow them to update the
information as required. This would not require a link to the
repository db.

The second application would use linked tables from the repository db
to "synch" the data. This would be a manually initiated process but
that's ok. This would involve queries to determine what data needed to
be updated back to the repository and what new data would be pulled
from it.

I've looked into replication but the addition of GUIDs and the
limitations imposed on the auto-number fields would make it a less than
desireable option.

Any advice?