Re: help needed understanding replication

Ok David... I read your message twice...

I cannot use Terminal Server... My application is used for contact
management. It uses C:\PROGRAM FILES\WINDOWS NT\DIALER.EXE in Windows XP.
All calls are logged and customer phone numbers are assigned to sales
people. The point is, they have to have a copy of the database on their
destop so XP Dialer can dial the phone number in their customers record, and
WinFax Pro can use the fax number in the customers record.

My Cisco VPN is connecting to the 2000 server and I can ping the 2000
server. I can map a drive to the Windows 2000 server with both the XP home
Edition and the XP Professional Edition using NET USE

Connectivity and security is my specialty. No problem there.

Remember, I only have 2 clients and one server. I am basiciccly a beta
tester. I can get this all setup like I want it then I can import the data
I need after all the goals are met. My production can continue while I
struggle with the installation.

So David, where do I start? What should I do first? Your the consultant, I
am the customer, What questions do you want to ask so you can help get to
step one?

Dale


"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
news:Xns9766CA1B15161f99a49ed1d0c49c5bbb2@xxxxxxxxxxxx
"Bikini Browser" <bikini.browser@xxxxxxxxx> wrote in
news:#jyuWLnLGHA.3856@xxxxxxxxxxxxxxxxxxxx:

Ok, I have read a lot about this now, but I need a place to get
started.

My needs are simple...

I have a Windows 2000 Server I have a full Class C License
available to me so a Static IP is not a problem.
I have two Windows XP computers. One is a home edition and other
is a Professional.
There is a CISCO Firewall that the 2000 server is behind.
Both XP's have a CISCO VPN Client working fine and connecting to
the 2000 server. I can Ping the server's netbios name without
problems

That all looks very good.

Now you'll need to check if the workstations can access and edit
data on the server via the VPN. If they can, that means they are
authenticating appropriately on the server and you won't have to
worry about that problem (which could be a major one).

I want to do the following with my Access database...

I want the XP clients to have current data on their copy of access
daily from remote locations.

Why not just host the application on Windows Terminal Server on the
server? Then the workstations won't have any complicated
configuration at all, just the Remote Desktop client. Obviously, if
the workstations can't be connected to the Internet at all times,
then that won't work, but if they are in an office that has an
always-on Internet connection (or could get one), you will save
yourself an enormous amount of work and headaches setting it up that
way. The cost of the monthly broadband service will be far less than
the costs in time it takes to set up indirect replication and keep
it running reliably.

I want the XP clients to be able to get feature updates on the
database as easy as possible and keep the same data from remote
locations.

This is not accomplished with replication, since the "program" MDB
(with forms, reports, etc.) cannot be replicated. Jet replication
works only for data tables, so you're going to have to push out
front end updates in some other fashion. That is not a replication
issue, though, so I'll let you investigate that separately. I'd
suggest checking the Google Groups archives for
comp.databases.ms-access.

I don't want the XP Clients to be able to modify their copy.

You mean the forms/reports, etc.? That can be accomplished by
distributing an MDE file, which will prohibit updates to any forms
or reports or modules (since the code will not be there -- read the
help file on MDE's). The only other method to accomplish this is via
Jet user-level security, and that's quite complicated to implement.
The MDE is going to be much easier.

I want a programmer to be able to make changes to the program and
add features.

Not a replication issue.

I want the Design master to reside on the Windows 2000 server and
no one will be making changes to the data on the master. All
changes will be made on the XP Clients.

Only the data MDB will be replicated. You will need to periodically
synch the DM with the live replica set or it will eventually expire.

Schema changes should not happen very often once the application is
in production use, so there shouldn't very often be a requirement to
synch the DM with the replica set beyond the periodic synch to keep
it from expiring (the default expiration term is 1,000 days).
However, you need to be careful with making schema changes to a
replicated data file that is in production use -- make them
incrementally, in small steps. If, for instance, you're changing the
relationships between two tables, remove the old relationship, then
synch through the whole replica set, then add the new relationship
and synch all 'round the replica set again. If all you're doing is,
say, adding a bunch of new fields to a new table, though, that can
all be done in one go. It's only when you're altering things that
affect the relationships between tables that you need to think
carefully and go slowly.

Thus, you want to make sure you've got your schema as close to
perfect as possible before you put it into production use.

Can anyone help me with step one? I am NOT a programmer. I can
only do things with Wizards. Can a MCSE do this? Or do I need
someone more qualified?

Well, if the PCs have to have to be used in a disconnected setting,
then you're going to have to do indirect replication, and you should
hire someone for that, as it *must* be someone with broad experience
in replication already, not someone who thinks he's an Access wiz
and can pick up what he needs to know about replication as he goes
along.

Alternatively, skip replication entirely, and host the application
on Windows Terminal Server. With decent bandwidth (DSL or highter),
the end users will find it just about the same as working locally
(though that will be dependent on the bandwidth of the two ends of
the connections).

I no longer ever do replication for supporting multiple offices that
want to share data -- I always do WTS hosted in one of the two
offices. I only do replication when laptops need to be carried into
the field and used there without an Internet connection. Mostly,
that's a case where the laptop is synched with the mother ship
before leaving the office, then used out of the office until the
return from the trip. At that point, all the data changes made by
the roving user are synched back with the mother ship while
connected to the LAN in the main office. That scenario requires no
programming -- it can use direct replication via the standard Access
replication UI.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/


.

Relevant Pages

  • Re: SBS 2003 and Replication Errors with Remote DC
    ... I just promoted the remote DC last week, so I still have time to solve the replication issues. ... Domain Controller Diagnosis ... Connecting to directory service on server alpha. ... Performing upstream analysis. ...
    (microsoft.public.windows.server.sbs)
  • Re: SBS 2003 and Replication Errors with Remote DC
    ... alpha server as soon as you can to get things going. ... A simple DNS replication test is to create a host record in the SBS server ... Domain Controller Diagnosis ...
    (microsoft.public.windows.server.sbs)
  • Re: SBS 2003 and Replication Errors with Remote DC
    ... I did make the changes that you suggested on the DNS of my alpha server and rebooted. ... I did run the simple DNS test that you suggested by adding a host record to my SBS server. ... A simple DNS replication test is to create a host record in the SBS server and wait till it shows up in the remote server. ...
    (microsoft.public.windows.server.sbs)
  • Re: Setting up SBS 2003 and Windows Server 2003, same domain, 2 sites..
    ... Generally speaking, when checking the replication status for a specifiedDC, ... 327644 How to configure licensing on an additional Windows server in an SBS ...
    (microsoft.public.windows.server.sbs)
  • RE: Help - Users cant log in ...
    ... I ran adprep/forestprep & domain prep on windows 2000 server ... I loaded Active directory to the 2003 server and made it a second DC ... > replication of Active Directory. ...
    (microsoft.public.windows.server.migration)