David,
Not sure that I fully understand what you are trying to tell me. Can you
either list or point me in the direction for "other methods"? The laptop
that goes out to the field will not have the ability to connect back to the
office via the internet. The Field computer will return back to the office
at the end of the day. If replication Manager isn't the way to go, then what
would you suggest I use when the laptop comes back to the office? Do I
create VBA code that does the exchange of data from the Field laptop
database to the main Office database (both will be Access 2010) or do you
have something else in mind.
As for splitting the database, I always do this when more than one person
wants access to the application. I'm very familiar with this setup.
Terminal Service, now called Remote Desktop by MS, would be great but they
will not have access to an internet connect while in the field.
If you limit synchs to when they are back in the office connected to the
wired LAN, then it's very easy to implement with plain old direct
replication.
if I decide to use this replication process when they come back to the
office, are you saying that it is easy to not only implement but maintain?
Do I need to have a tech person available every time a field laptop comes
into the office and attempts to sync? Once the process is setup and tested,
is it pretty user friendly?
I'm very comfortable with VBA coding, if coding a good procedure to move
data from one database to another is the way the go, then I would rather
take that approach. What do you recommend?
Thank you,
"David W. Fenton" wrote in message
36.94...
"Thomas Kroljic" wrote in
:
And my second question would have to do with any changes that I
would need to make to the data structure. How do I update the
Field databases? Again, would it be better to write the vba code
to modify the data sturctures instead of using Replication
Manager?
I envision very few changes to the database sturcture. But I
can see
forms, reports, queries... being added or updated.
Why you mention Replication Manager, I don't know. It's an
out-of-date tool that doesn't provide much in the way of
functionality that you can't get via other metods.
See the Jet Replication Wiki for somewhat comprehensive info:
http://dfenton.com/DFA/Replication/
Now, to some issues:
1. as others have said, your app needs to be split, front end
(forms/reports, etc.) and back end (data tables). Only the back end
should be replicated, as:
a. replication is not needed to push out changes to a front end.
b. replication doesn't work reliably with anything but pure Jet
objects (tables/queries).
Your app should be split in this form even if you're *not* using
replication.
2. if the users are always connected to the Internet when away from
the central office, you'd be much better off avoiding replication
entirely and using Windows Terminal Server as your remote host for
the app.
3. if your users need to work outside the office disconnected from
the Internet, then using a local replica is a great way to manage
that. If you limit synchs to when they are back in the office
connected to the wired LAN, then it's very easy to implement with
plain old direct replication. If they want to synch in the field
(with an occasional Internet connection) or they need to synch
across a WiFi or WAN connection, then you would have to use indirect
replication which is an order of magnitude or more harder to
implement and much more difficult to keep running reliably (because
there are so many more "moving parts"). If you need remote synchs,
then I'd recommend upgrading to Access 2010 and using Sharepoint
2010 instead. That allows both offline editing and easy synching
when connected.
Basically, even though I'm one of the few people who has a lot of
knowledge of Jet replication, I recommend against using it except in
a very narrow range of circumstances. A2010 and Sharepoint 2010
remove the last of those except for those who can't afford the
dependency on a Sharepoint server.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/