[AccessD] AccessD Digest, Vol 43, Issue 8

Stuart McLachlan stuart at lexacorp.com.pg
Sat Sep 9 17:03:23 CDT 2006


I see it all now (I too couldn't quite grasp the situation from your 
description).

Replication is definitely the way to go here.

The individual who said that replication doesn't work with referential 
integerity has probably tried to replicate systems which use Autonumber 
Primary Keys with the default defininiton as Longs and using the PK as a 
autoincrementing meaningful number.   In a replicated system, ANPKs are 
always "random numbering" and should generally be of type  "Replication ID"

Grab a copy of  the "Microsoft Access 2000, Microsoft Access 2002, and 
Microsoft Office Access 2003 Replication FAQ"

"The ReplFAQJet40.exe file contains a Microsoft Word document titled 
"Frequently Asked Questions About Microsoft Access 2000, Microsoft Access 
2002, and Microsoft Office Access 2003 Replication" written by Michael 
Kaplan, Mary Chipman, Paul Litwin, Steve Thompson, and John Blaine. This 
document answers many Microsoft Access replication questions you may have."

Available at http://support.microsoft.com/kb/q282977/

DIrect download link:

http://download.microsoft.com/download/4/2/c/42c1f8e7-ae0d-4dcd-ac90-
efddcfc29898/replfaqjet40.exe



On 9 Sep 2006 at 16:26, ewaldt at gdls.com wrote:

> The answer to nearly all of your questions is found in my (apparently less
> than clear statement):
> 
>       "For purposes of security, it cannot be on a network drive shared by
> the two companies."
> 
> I guess the problem is the word "security". Don't think of "database
> security" or "network security"; note that I work for General Dynamics, and
> think of "military security" or even "national security" instead, although
> that might be a bit of overkill.
> 
> We are working with another company. We cannot have a normal shared network
> with them; again, that's because of security (see above). We can, however
> deposit the database in a very secure place where they can pick it up, use
> it, return it, and then we pick it up again. I was hoping that replication
> might avoid this.
> 
> Thomas F. Ewald
> FCS Database Manager
> General Dynamics Land Systems
> (586) 276-1256
> 
> 
> Message: 16
> Date: Thu, 7 Sep 2006 14:45:36 -0700 (PDT)
> From: <artful at rogers.com>
> Subject: Re: [AccessD] Replication and Referential Integrity
> To: Access Developers discussion and problem solving
>              <accessd at databaseadvisors.com>
> Message-ID: <20060907214536.55515.qmail at web88205.mail.re2.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
> 
> I have mined Access replication extensively and like to pretend that I know
> it very well. So perhaps I can help in that regard. However, before we go
> there, I must say that I think something is very wrong if only one company
> can use the database at a time. Perhaps you are so fortunate that they
> reside in time zones that will never collide.
> 
> IMO, your first question should be, Why is it that only one company can use
> the DB at a time? (And secondly, does this mean that 20 users within one
> company can use it simultaneously? Or is it even worse?) I have been trying
> for the past few minutes (not long, admittedly), but I cannot see a
> situation which forces you into this "one-company" scenario. Further, I
> don't see how replication will get you out of this problem, which seems to
> me of your own creation.
> 
> Using replication strictly within Access, I have successfully tied together
> 4 branches distributed across North America, with a total of about 70 users,
> everyone hitting the same fixed-inventory tables. I can say with confidence
> that when this is set up correctly, nothing goes wrong. Not a single
> collision in over six months of operation. (After that we migrated to SQL
> Server.)
> 
> So back to your original question. What is lacking in the design that
> forces you to restrict access to just one company? Something is strange in
> Denmark, methinks. Without knowing anything about your DB, at the very least
> I might suggest creating a Companies table and inheriting its PK in all the
> immediate tables, so that Company 1's customers have an FK pointing to
> Company 1, etc. This would effectively isolate all rows from each company,
> and also permit adding Company 3.
> 
> Or perhaps I'm missing something.
> 
> ----- Original Message ----
> From: ewaldt at gdls.com
> To: accessd at databaseadvisors.com
> Sent: Thursday, September 7, 2006 3:57:39 PM
> Subject: [AccessD] Replication and Referential Integrity
> 
> I've created a database that is used by two companies. For purposes of
> security, it cannot be on a network drive shared by the two companies. More
> detail isn't really necessary. What it amounts to is that only one company
> can use it at a time.
> 
> I have had replication suggested to me. I know what it is, of course, but
> have only played with it on a very minor and experimental basis. However,
> the individual who recommended it to me is more experienced with it, and he
> said that it cannot be used with a database that employs referential
> integrity. Is he correct? I am sure that he knows more than I do about
> replication, but that doesn't mean much.
> 
> TIA.
> 
> 
> Thomas F. Ewald
> FCS Database Manager
> General Dynamics Land Systems
> (586) 276-1256
> 
> 
> 
> 
> 
> 
> This is an e-mail from General Dynamics Land Systems. It is for the intended
> recipient only and may contain confidential and privileged information.  No
> one else may read, print, store, copy, forward or act in reliance on it or
> its attachments.  If you are not the intended recipient, please return this
> message to the sender and delete the message and any attachments from your
> computer. Your cooperation is appreciated.
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com

-- 
Stuart





More information about the AccessD mailing list