Primary keys

[Guest]

Hi,

I know there are plenty of primary key questions / answer posts, but here
goes a new one...

I have a single record table that stores setup / configuration info for my
mdb (Rather than using an ini file). One field here identifies the
[CompanyNameID] which is an abbreviated unique code / key (Not being used as
the primary key since there is only one record, but could be). In another
table I have records of [Customers] (For the purpose of the question) with a
primary key to identify each.

I need to be able to send some information on customers to other mdb's,
external to the initial system, but I'm not sure how to best uniquely
identify them. Should I:

- Within the first mdb, in the [Customers] table have the [CoNameID] as a
related field, with a relationship between both key fields? Internal to the
first mdb this is redundant, but to want to view info from another mdb is. It
also means in the first or main mdb all queries etc... must accomodate this
[CoNameID] field.

- For any data forwarded to another mdb should this include the necessary
key info, and when imported stored in a seperate [Customer] table altogether?


- Are there other approaches where I may use another table to track the
[CoNameID] fields, or make the config table multiple records with one record
marked as the primary [Company]?

Bottom line is, I'm trying to solve local issues of building queries / forms
etc... yet still maintain unique overall identities for when data needs to be
shared with other mdb's.

Thanks in advance for any thoughts - or suggested reading material.


swas

 

[Guest]

Why not set up a back end MDB that all of the other MDB's link to. It will
contain just the number table with an autonumber field. Whenever a new number
is required, just insert a row to this table and take the number.

Dorian

 

[Guest]

Dorian,

I understand the logic. The front mdb's are not on the same network, and
there needs to be isolation between the data shares - ie. A might send info
to B & C, but B & C can't see each other. This could be done within the
tables though.

I was intending using xml for the inter-mdb stuff, via an ftp server since
they are not always online.

Your option has some valid merit, so I need to 'chew' the info for a while,
until I model the overall picture.

Thanks for the thoughts.

Why not set up a back end MDB that all of the other MDB's link to. It will
contain just the number table with an autonumber field. Whenever a new number
is required, just insert a row to this table and take the number.

Dorian

Hi,

I know there are plenty of primary key questions / answer posts, but here
goes a new one...

I have a single record table that stores setup / configuration info for my
mdb (Rather than using an ini file). One field here identifies the
[CompanyNameID] which is an abbreviated unique code / key (Not being used as
the primary key since there is only one record, but could be). In another
table I have records of [Customers] (For the purpose of the question) with a
primary key to identify each.

I need to be able to send some information on customers to other mdb's,
external to the initial system, but I'm not sure how to best uniquely
identify them. Should I:

- Within the first mdb, in the [Customers] table have the [CoNameID] as a
related field, with a relationship between both key fields? Internal to the
first mdb this is redundant, but to want to view info from another mdb is. It
also means in the first or main mdb all queries etc... must accomodate this
[CoNameID] field.

- For any data forwarded to another mdb should this include the necessary
key info, and when imported stored in a seperate [Customer] table altogether?


- Are there other approaches where I may use another table to track the
[CoNameID] fields, or make the config table multiple records with one record
marked as the primary [Company]?

Bottom line is, I'm trying to solve local issues of building queries / forms
etc... yet still maintain unique overall identities for when data needs to be
shared with other mdb's.

Thanks in advance for any thoughts - or suggested reading material.


swas