multiple relationships between 2 tables

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello and thanks for looking into my question,

I have a table of servers which is related to a table of server services via
the server name field (pid). This is a 1 to 1 relationship because for each
server in one table, there can only be one entry for it's services in the
other table. This relationships works great. For clarification, here's my
setup below.

tbl_ServerName (1st table)
------------------
serverName (pid)

tbl_ServerServices (2nd table)
---------------------
serverName (pid) (linked to my 1st table via a 1-to-1)
serverService1
serverService2
serverService3

Ok, now my serverService1 field in the 2nd table above is linked to a third
table listing all of the server services. This is a one to many relationship.
It works great too. Here is the what the 3rd table looks like:

tbl_Service (3rd table)
------------
service (pid) (now linked to serverService1 field in 2nd table via 1-to-many.)

My question is that I would also like to link my serverService2 and
serverService3 fields above to the same third table. This way, if I make any
changes to any of the server services in the third table, it also shows up in
the 3 fields on my 2nd table.

Is this even possible? Please advise.

Thank you in advance.

-Blenvid
 
Stop...
Consider creating a table of server services like:

tbl_ServerServices
----------------------------
serverName
service

A record is created for each service on each server. If a server has 20
services, there should be 20 records.
 
Hi Duane,

Thanks for responding to my question.

That would solve the problem. This would create some work for me though;
I've got 173 servers, some with 3 services each.

Is the way that I'm trying to do it incorrect?

-Blenvid
 
Blenvid said:
Hello and thanks for looking into my question,

I have a table of servers which is related to a table of server services via
the server name field (pid). This is a 1 to 1 relationship because for each
server in one table, there can only be one entry for it's services in the
other table. This relationships works great. For clarification, here's my
setup below.

tbl_ServerName (1st table)
------------------
serverName (pid)

tbl_ServerServices (2nd table)
---------------------
serverName (pid) (linked to my 1st table via a 1-to-1)
serverService1
serverService2
serverService3
Click to expand...

I get the impression that [serverService2] is the same kind of beast as
[serverService1]. If so, I suggest that they share ONE field in some
Table, instead of occupying separate fields. Access will work with them
in separate fields, but you'll make extra work for yourself doing it
that way.
Ok, now my serverService1 field in the 2nd table above is linked to a third
table listing all of the server services.
Click to expand...

Linked how? I assume it somehow contains a reference to the primary key
(not shown) in your [tbl_Service] Table. But if so, it wouldn't be
one-to-many, as one field can't contain "many" values.

What I think you want is many services linked to one server; i.e., many
records in [tbl_Service] that contain a reference to a
[tbl_ServerName].[serverName] key value.
This is a one to many relationship.
It works great too. Here is the what the 3rd table looks like:

tbl_Service (3rd table)
Click to expand...

"1-to-many" suggests that for each service (represented by a record in
[tbl_Service]) you can have several servers (represented by records in
[tbl_ServerName]) that share it. I assume you have other fields in
[tbl_Service] as well, containing useful information about the actual
service. The [tbl_Service].[service] field serves mainly to identify a
record and I assume does little else, although you could legitimately
have it do double duty, using a unique name for the service that means
something to human beings. But I usually prefer a meaningless key, such
as an Autonumber field, that won't have to change if you change some
other field in a record. If you used a real name there, and you
discover that it's misspelled, you'd have to change it not only there
but also everywhere else in the database that it appeared; there'd be no
reason to change an Autonumber key value.

Since [tbl_ServerServices] can associate three [tbl_Service] records
with one [tbl_ServerName] record, this looks like a "many-to-many"
relationship. That will work, but it requires an extra Table in which
each record associates one server with one of the services, and maybe
also tells which of the 3 services that is.

For example, you could revise the design of your 2nd table to look like
this:

[tbl_ServerServices] (revised 2nd table)

[serverName] (link to 1st Table, via many-to-1)
[service] (link to 3rd Table, via many-to-1)
[Number] (=1, 2, or 3, to specify which service this is)

With all 3 Tables linked, you now have a many-to-many relationship
defined that (I think) reflects what you want to keep track of.
My question is that I would also like to link my serverService2 and
serverService3 fields above to the same third table. This way, if I make any
changes to any of the server services in the third table, it also shows up in
the 3 fields on my 2nd table.
Click to expand...

With the design I suggested, your change will show up in any record
(which you'd display via a Query) in which some server uses that service.
Is this even possible? Please advise.

Thank you in advance.

-Blenvid
Click to expand...

HTH.

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.
 
Blenvid said:
Hi Duane,

Thanks for responding to my question.

That would solve the problem. This would create some work for me though;
I've got 173 servers, some with 3 services each.

Is the way that I'm trying to do it incorrect?

-Blenvid
Click to expand...

Yes, there'll be some work, but it's a one-time project; you won't have
to redo it.

If you had thousands of servers, I'd suggest writing Append Queries to
copy the information to [tbl_ServerServices]. You'd do that 3 times,
once for each of the 3 values.

But with only 173 records, you might find it easier to copy your current
[tbl_ServerServices] Table, let's say to [tbl_New], rename the
[serverService1] field in the copy to [Service], and delete the other 2
fields. Also change the [serverName] field so that it doesn't have to
be unique. That takes care of [serverService1].

Now make another copy of [tbl_ServerServices], let's say to Table [t2],
and this time delete [serverService1] and [serverService3] and make
[serverName] not unique. Rename the fields in [t2] to match the field
names in [tbl_New]. In the Database window, copy this Table and paste
it; select "Append Data to Existing Table", and specify "tbl_New" as the
Table Name. If you get an error message, correct the mistake and try
again; otherwise, the data are appended and you can delete table [t2].

Now make another copy of [tbl_ServerServices], let's say to Table [t3]
and do the same as with [t2] but keeping [serverService3] this time.

Now [tbl_New] contains all the records you need. Sort it by its
[Service] field and delete the records where that field is blank.
Rename or delete the old [tbl_ServerServices] Table, and rename
[tbl_New] to call it "tbl_ServerServices". You may also want to add a
primary key to it (I'd suggest an Autonumber field), but that may not be
strictly necessary.

Link the fields in the new [tbl_ServerServices] Table to the other 2
Tables, using the Relationships window, and you're in business.

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.
 
Vincent Johns wrote:

[...]
If you had thousands of servers, I'd suggest writing Append Queries to
copy the information to [tbl_ServerServices]. You'd do that 3 times,
once for each of the 3 values.

But with only 173 records, you might find it easier to copy your current
[tbl_ServerServices] Table, ...
Click to expand...

Oops -- I think I forgot to mention that it's an excellent idea to make
a BACKUP COPY of your database file before doing anything like this!
(As well as on many other occasions, such as before thunderstorms and
hard-disk crashes.)

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.
 
Hi Vincent,

Thank you also for your reply.

Please note, my 3rd table looks like this:

tbl_Service (3rd table)
------------
service (pid) (now linked to serverService1 field in 2nd table via 1-to-many.)

I chose to go with the service field as my PID because each services name in
itself is descriptive. There are other fields, but I don't want to make
things seemingly more complex by including them. :)

For each original record in [tbl_Service.service] above, there are many
records in [tbl_ServerServices.serverService1]. In my relationships view in
Access, this is shown of course as 1 on the [tbl_Service.service] side, and 8
sideways on the [tbl_ServerServices] side.

I am a little confused by your response. Please clarify your comment, "Since
[tbl_ServerServices] can associate three [tbl_Service] records with one
[tbl_ServerName] record, this looks like a "many-to-many" relationship."

You are right on the money here Vincent:

"> What I think you want is many services linked to one server; i.e., many
records in [tbl_Service] that contain a reference to a
[tbl_ServerName].[serverName] key value."
Click to expand...

This is exactly what I want.

-Blenvid


Vincent Johns said:
Blenvid said:
Hello and thanks for looking into my question,

I have a table of servers which is related to a table of server services via
the server name field (pid). This is a 1 to 1 relationship because for each
server in one table, there can only be one entry for it's services in the
other table. This relationships works great. For clarification, here's my
setup below.

tbl_ServerName (1st table)
------------------
serverName (pid)

tbl_ServerServices (2nd table)
---------------------
serverName (pid) (linked to my 1st table via a 1-to-1)
serverService1
serverService2
serverService3
Click to expand...

I get the impression that [serverService2] is the same kind of beast as
[serverService1]. If so, I suggest that they share ONE field in some
Table, instead of occupying separate fields. Access will work with them
in separate fields, but you'll make extra work for yourself doing it
that way.
Ok, now my serverService1 field in the 2nd table above is linked to a third
table listing all of the server services.
Click to expand...

Linked how? I assume it somehow contains a reference to the primary key
(not shown) in your [tbl_Service] Table. But if so, it wouldn't be
one-to-many, as one field can't contain "many" values.

What I think you want is many services linked to one server; i.e., many
records in [tbl_Service] that contain a reference to a
[tbl_ServerName].[serverName] key value.
This is a one to many relationship.
It works great too. Here is the what the 3rd table looks like:

tbl_Service (3rd table)
Click to expand...

"1-to-many" suggests that for each service (represented by a record in
[tbl_Service]) you can have several servers (represented by records in
[tbl_ServerName]) that share it. I assume you have other fields in
[tbl_Service] as well, containing useful information about the actual
service. The [tbl_Service].[service] field serves mainly to identify a
record and I assume does little else, although you could legitimately
have it do double duty, using a unique name for the service that means
something to human beings. But I usually prefer a meaningless key, such
as an Autonumber field, that won't have to change if you change some
other field in a record. If you used a real name there, and you
discover that it's misspelled, you'd have to change it not only there
but also everywhere else in the database that it appeared; there'd be no
reason to change an Autonumber key value.

Since [tbl_ServerServices] can associate three [tbl_Service] records
with one [tbl_ServerName] record, this looks like a "many-to-many"
relationship. That will work, but it requires an extra Table in which
each record associates one server with one of the services, and maybe
also tells which of the 3 services that is.

For example, you could revise the design of your 2nd table to look like
this:

[tbl_ServerServices] (revised 2nd table)

[serverName] (link to 1st Table, via many-to-1)
[service] (link to 3rd Table, via many-to-1)
[Number] (=1, 2, or 3, to specify which service this is)

With all 3 Tables linked, you now have a many-to-many relationship
defined that (I think) reflects what you want to keep track of.
My question is that I would also like to link my serverService2 and
serverService3 fields above to the same third table. This way, if I make any
changes to any of the server services in the third table, it also shows up in
the 3 fields on my 2nd table.
Click to expand...

With the design I suggested, your change will show up in any record
(which you'd display via a Query) in which some server uses that service.
Is this even possible? Please advise.

Thank you in advance.

-Blenvid
Click to expand...

HTH.

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.
Click to expand...
 
Blenvid said:
Hi Vincent,

Thank you also for your reply.

Please note, my 3rd table looks like this:

tbl_Service (3rd table)
------------
service (pid) (now linked to serverService1 field in 2nd table via 1-to-many.)

I chose to go with the service field as my PID because each services name in
itself is descriptive.
Click to expand...

OK. But if it's a long name, and the same name is used often, you might
save space by storing the names somewhere else and linking to them with
a number field. Also, if you ever need to change the name, you'll have
to make the same change everywhere it appears in every other Table
linking to this one.
There are other fields, but I don't want to make
things seemingly more complex by including them. :)
Click to expand...

That's what I thought, but sometimes a Table can be useful even if it
contains only one or two fields, so I wasn't sure.
For each original record in [tbl_Service.service] above, there are many
records in [tbl_ServerServices.serverService1]. In my relationships view in
Access, this is shown of course as 1 on the [tbl_Service.service] side, and 8
sideways on the [tbl_ServerServices] side.
Click to expand...

But that's only to the first field, [tbl_ServerServices.serverService1],
isn't it? Having linked the record via that field, I'm not sure what it
would mean to try to also link it via some other field, such as
[tbl_ServerServices.serverService3].

(Incidentally, the "oo" symbol means "infinity" or "endlessness" in
mathematics; here it just means we don't care where it ends, it just
doesn't have to end with 1 record.)
I am a little confused by your response. Please clarify your comment, "Since
[tbl_ServerServices] can associate three [tbl_Service] records with one
[tbl_ServerName] record, this looks like a "many-to-many" relationship."
Click to expand...

That was my guess, based on what you'd said earlier. The statement by
itself isn't sufficient to generate that "many-to-many" conclusion. But
it also looked to me as if one service ([tbl_Service] record) might be
referred to by more than one server.

If you know that that will never be the case, then you do have 1
(server) to many (services), and you don't need the third Table. In
that case, you'd just store a server reference into each record in
[tbl_Service] instead of what I suggested. There'd be no need for the
2nd Table. The other field I suggested, [Number], showing that a
service is number 1, 2, or 3 in your current [tbl_ServerServices] list,
you could store in the [tbl_Service] Table, if you needed to keep track
of that.
You are right on the money here Vincent:

"> What I think you want is many services linked to one server; i.e., many
records in [tbl_Service] that contain a reference to a
[tbl_ServerName].[serverName] key value."
Click to expand...

This is exactly what I want.

-Blenvid
Click to expand...

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.
 
Thanks so much for your continued support here Vincent. You're spending some
good time on my situation and I really appreciate it. :)

Actually, one of the benefits of relationships is that if you change a
name/field in one place, it will update the name/field in related tables?
That's really my biggest interest in doing all of this, although I doubt
someone will change the entry, "DNS," in the future. (Maybe someday there'll
be a DNS v.2, like IP addressing ex. ipv6) The names are quite short too. The
longest one is "Active Directory."

Anyway, your paragraph here:
But that's only to the first field, [tbl_ServerServices.serverService1],
isn't it? Having linked the record via that field, I'm not sure what it
would mean to try to also link it via some other field, such as
[tbl_ServerServices.serverService3].
Click to expand...

I actually have tried this. I can link all 3
[tbl_ServerServices.serverServiceX] fields via a relationship, but it's not
with Referential Integrity, the whole reason for linking them in the first
place. In the "Edit relationships" prompt, you can select multiple fields. I
selected [tbl_Service.service] as my source field, then selected the 3 fields
of serverServices 1, 2, and 3. I get an error message with Referential
Integrity checked. Here is the error message:

"Microsoft Access can't enforce referential intergrity for this
relationship. Make sure the fields you drag are primary key fields or
uniquely indexed and that the unique index or primary key is correctly set.
If you want to create the relationship without the rules of referential
integrity, clear the Enforce Referential Integrity check box."

I need some time to look at this paragraph:
If you know that that will never be the case, then you do have 1
(server) to many (services), and you don't need the third Table. In
that case, you'd just store a server reference into each record in
[tbl_Service] instead of what I suggested. There'd be no need for the
2nd Table. The other field I suggested, [Number], showing that a
service is number 1, 2, or 3 in your current [tbl_ServerServices] list,
you could store in the [tbl_Service] Table, if you needed to keep track
of that.
Click to expand...

This may be the answer. Do you mean that I should create a number field in
[tbl_Service] for each service? Then in the [tbl_ServerServices] table, use
the number to distinguish between services? If this is the answer, how would
I then be able to link them with Referential Integrity?

-Blenvid
 
Vincent said:
if you ever need to change the name, you'll have
to make the same change everywhere it appears in every other Table
linking to this one.
Click to expand...

Choose ON UPDATE CASCADE on the FOREIGN KEY constraints and the system
does for you.
 
Blenvid said:
Was your post directed at me or Mr. Johns?
Click to expand...

It was directed at readers <g>. My point is "you'll have to make the
same change everywhere" is not a valid argument against your 'natural'
key. With ON UPDATE CASCADE you only have to change the referenced
table and the change is automatically propagated to all referencing
tables.
 
It was directed at readers <g>. My point is "you'll have to make the
same change everywhere" is not a valid argument against your 'natural'
key. With ON UPDATE CASCADE you only have to change the referenced
table and the change is automatically propagated to all referencing
tables.
Click to expand...

Yes, this is a convenient feature of Access, but it doesn't always work.

For example, I think it requires specifying referential integrity. (Is
there some other way to invoke it?) Assuming I'm correct, suppose you
have *other* random references in other Tables that are linked but
without using referential integrity. For example, suppose there are
missing data that you can easily handle via outer joins in Queries but
that can't be connected with referential integrity enforced. Then you'd
have extra work to do if any key value changes.

I'll concede that you aren't likely to need to change primary key values
often, and that some of the work can be done automatically. But often
the extra effort on your part to set up a separate (meaningless)
Autonumber field to serve as the primary key isn't very great, and as it
takes only 4 bytes per record it doesn't require a huge amount of space,
and Access can sort it about as quickly as it can sort any set of values.

However, if you want to use a real (unique) datum as the primary key,
that will work, and it may occasionally save time by letting you display
a key value directly instead of looking it up in the foreign Table.

Incidentally, as you may have guessed, I feel that concerns about
efficiency (speed and memory space used) can be overblown -- if you're
really concerned about those, you shouldn't be using an RDBMS like
Access at all. I feel that the main purpose of Access is to make life
easier by helping you organize your information in a flexible manner, so
my suggestions tend toward keeping solutions as simple to understand
as is reasonably possible, rather than toward minimizing resource use
(but I also try to avoid unnecessary waste).

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.
 
Vincent said:
suppose you
have *other* random references in other Tables that are linked but
without using referential integrity. For example, suppose there are
missing data that you can easily handle via outer joins in Queries but
that can't be connected with referential integrity enforced.
Click to expand...

I'm not sure I follow. How will using a number 'artificial' key in
place of the text 'natural' key help you out of this hole?

One 'real life' situation I can think of where you cannot use DRI is
across database boundaries e.g. a table in one .mdb which 'references'
a table in another .mdb file. In this scenario, using an externally
verifiable 'natural' key is especially important.
 
Blenvid said:
Thanks so much for your continued support here Vincent. You're spending some
good time on my situation and I really appreciate it. :)

Actually, one of the benefits of relationships is that if you change a
name/field in one place, it will update the name/field in related tables?
That's really my biggest interest in doing all of this, although I doubt
someone will change the entry, "DNS," in the future. (Maybe someday there'll
be a DNS v.2, like IP addressing ex. ipv6) The names are quite short too. The
longest one is "Active Directory."
Click to expand...

Yes, if you set it up that way (as (e-mail address removed) mentioned in
another posting). And it may not be a concern if the names are pretty
stable; as you say, you don't expect any changes.
Anyway, your paragraph here:

But that's only to the first field, [tbl_ServerServices.serverService1],
isn't it? Having linked the record via that field, I'm not sure what it
would mean to try to also link it via some other field, such as
[tbl_ServerServices.serverService3].
Click to expand...

I actually have tried this. I can link all 3
[tbl_ServerServices.serverServiceX] fields via a relationship, but it's not
with Referential Integrity, the whole reason for linking them in the first
place. In the "Edit relationships" prompt, you can select multiple fields. I
selected [tbl_Service.service] as my source field, then selected the 3 fields
of serverServices 1, 2, and 3. I get an error message with Referential
Integrity checked.
Click to expand...
[...]

Just because Access lets you do something doesn't mean that it makes
sense. And in this case, you're lucky, as Access gave you a message
instead of doing something confusing.

I still can't see any value in linking more than one of those fields,
perhaps because I don't know what they mean. It might make sense to do
that if you have a [Year] and a [Month] field, neither of which would
uniquely identify June 2005, and you could link both of them to
corresponding fields in another Table. But I don't think you're doing
that here. All 3 of these fields look like copies of the same kind of
beast, only with possibly different data.
I need some time to look at this paragraph:

If you know that that will never be the case, then you do have 1
(server) to many (services), and you don't need the third Table. In
that case, you'd just store a server reference into each record in
[tbl_Service] instead of what I suggested. There'd be no need for the
2nd Table. The other field I suggested, [Number], showing that a
service is number 1, 2, or 3 in your current [tbl_ServerServices] list,
you could store in the [tbl_Service] Table, if you needed to keep track
of that.
Click to expand...


This may be the answer. Do you mean that I should create a number field in
[tbl_Service] for each service?
Click to expand...

You could do that. I'm still not sure how a [serverService2] field
differs from a [serverService1] field. But a [Number] (or [Type] or
[Sequence] or [Descriptor], whatever name is most suggestive of what
this thing really means) field will let you distinguish between
otherwise similar field values.
Then in the [tbl_ServerServices] table, use
the number to distinguish between services?
Click to expand...

Or wherever you need to do that. I don't see a Table doing any
distinguishing; Tables mostly just hold data. But you might want to set
up Queries that would do calculations based on this [Number] value.

Note that, if you do add a [Number] field to [tbl_Service], any
reference to a record in [tbl_Service] will automatically give you
access to the [Number] value for that record, and there's no point in
trying to store a copy of [Number] anywhere else.
If this is the answer, how would
I then be able to link them with Referential Integrity?
Click to expand...

By being sure you have matching values. The integrity has to be there
before you can enforce it. That's easiest, of course, before you begin
populating your Tables, as there's nothing there at first to object to.
With non-empty Tables, you might get a nasty message from Access
saying that some key value doesn't match, and it's not necessarily easy
to determine which one -- with tens of thousands of records, you might
need to run some preliminary Queries to identify problems before you try
to enforce referential integrity.
 
I'm not sure I follow. How will using a number 'artificial' key in
place of the text 'natural' key help you out of this hole?
Click to expand...

Because, since the 'artificial' key (generated via Autonumber or some
other method) doesn't actually mean anything, there'll never be a reason
to have to change it. If it meant something, such as a product number,
an external change (e.g., revised product list received from the
manufacturer) might force a change to the key, or at least make it
obsolete -- it would become an old name and could be misleading. I like
to avoid misleading stuff; keeping things as clear as possible now saves
many headaches later.
One 'real life' situation I can think of where you cannot use DRI is
across database boundaries e.g. a table in one .mdb which 'references'
a table in another .mdb file. In this scenario, using an externally
verifiable 'natural' key is especially important.
Click to expand...

Perhaps. But what I'd consider especially important is that the linked
records remain linked. If I have another *.mdb referring to the one
containing the Table with the Autonumber field, I'd still want the
records in it to use the key values established in the referred-to
Table. Having the references in some other *.mdb file (or even written
down in pencil on some paper form) wouldn't change that.

Incidentally, if some human being actually had to copy the key values,
which I think would be an unfortunate design, I'd want the values
themselves to be short and easy to write, so in that case I might set
the New Values property of that field to "Increment" instead of
"Random". But normally I prefer "Random", and I would suggest to the
customer that the poor data-entry person be given something meaningful
to record, such as a part number.

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.
 
If anybody could assist me with a solution for this, I'd really
appreciate it.
Click to expand...

You haven't really explained _what_ you are trying to do; only _how_ you
have tried to achieve it so far...


Genuine reasons for 1:1 relationships are pretty uncommon, and there is
no hint here that you have one of those situations.

It's a no-brainer that this is a Design Problem. These fields should be
three rows in a single table

I don't really understand how this is different to any other bog-standard
many-to-many relationship:

Servers
=======
*PublicName
CPUType
IPAdddress, etc etc etc

Services
========
*ServiceID
PrimaryName
OwnedBy
CostPerCycle
NeedsPrinter, etc etc etc

Provides
========
*Service FK references Services(ServiceID)
*ServedOn FK references Servers(PublicName)
ReliablityPerCent
PrimaryOrSecondary etc etc etc


.... but then again it's all guess work from here.


Best wishes


Tim F
 
Hi Tim,

Please note from my original message:

"My question is that I would also like to link my serverService2 and
serverService3 fields above to the same third table. This way, if I make any
changes to any of the server services in the third table, it also shows up in
the 3 fields on my 2nd table.

Is this even possible? Please advise."

Your suggestion Tim, "It's a no-brainer that this is a Design Problem. These
fields should be three rows in a single table," was already suggested in the
beginning. I was hoping for other possible solutions. Others had started
putting possible solutions up.

Alas, I have gone ahead re-entered my data with the three fields from before
comprised into three seperate entries, three rows. It took me hours to do it
with all the data I have, but I guess that's what happens when your design is
wrong.

Thanks for your time everyone who contributed.

-Blenvid
 
Your suggestion Tim, "It's a no-brainer that this is a Design Problem.
These fields should be three rows in a single table," was already
suggested in the beginning. I was hoping for other possible solutions.
Click to expand...

What can I say? Common things are common; so commonly different
situations will have the same correct solution.
Alas, I have gone ahead re-entered my data with the three fields from
before comprised into three seperate entries, three rows. It took me
hours to do it with all the data I have, but I guess that's what
happens when your design is wrong.
Click to expand...

You were also offered ways of transferring the data from the non-normal
design to the normal one using queries, rather than hand-typing. Have you
devised a good method for checking the new data against the old ones to
make sure you did not make any mistakes?

And yes: it's always cheaper (in time, effort, embarrassment etc) to pick
up design problems at the design stage than later on... <g>

Best wishes


Tim F
 
Back
Top