Home/ Questions/Q 9162167
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T14:08:46+00:00

I’m having a problem with my students using multi-valued fields in access and getting

  • 0

I’m having a problem with my students using multi-valued fields in access and getting confused about normalisation as a result.

Here is what I can make out. Given a 1-to-many relationship, e.g.

Articles    Comments
--------    --------
artID{PK}   commID{PK}
text        text
            artID{FK}

Access makes it possible to store this information into what appears to be one table, something like

Articles
--------
artID{PK}
text
comment
   + value

“value” referring to multiple comment values for the comment “column”, which access actually stores as a separate table. The specifics of how the values are stored – table, its PK and FK – is completely hidden, but it is possible to query the multi-valued field, e.g. in the example above with the query

INSERT INTO article( [comment].Value )
VALUES ('thank you')
WHERE artID = 1;

But the query doesn’t quite reveal the underlying structure of the hidden table implementing the multi-valued field.

Given this (disaster, in my view) – my problem is how to help newcomers to database design and normalisation understand what Access is offering them, why it may not be helpful, and that it is not a reason to ignore the basics of the relational model. More specifically:

  • Are there better ways, besides queries as above, to reveal the structure behind multi-valued fields?
  • Are there good examples of where the multi-valued field is not good enough, and shows the advantage of normalising explicitly?
  • Are there straightforward ways to obtain the multi-select visual output of Access multi-values, but based on separate, explicit tables?

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I cannot give you advice in using this feature, because I never used it; however, I can give you reasons not to use it.

    • I want to have full control on what I’m doing. This is not the case for multi-valued fields, therefore I don’t use them.

    • This feature is not expandable. What if you want to add a date field to your comments, for instance?

    • It is sometimes necessary to upsize an Access (backend) database to a “big” database (SQL Server, Oracle). These Databases don’t offer such a feature. It is often the customer who decides which database has to be used. Recently I had to migrate an Access application (frontend) using an Oracle backend to a SQL-Server backend because my client decided to drop his Oracle server. Therefore it is a good idea to restrict yourself to use only common features.

    • For common tasks like editing lookup tables I created generic forms. My existing solutions will not work with multi-valued fields.

    • I have a (self-made) tool that synchronizes changes in the structure of the database on my developer’s site with the database on the client’s site. This tool cannot deal with multi-valued fields.

    • I have tools for the security management that can grant SELECT, INSERT, UPDATE and DELETE rights on tables or revoke them. Again, the management tool does not work with multi-valued fields.

    • Having a separate table for the comments allows you to quickly inspect all the comments (by opening the table). You cannot do this with multi-valued fields.

    • You will not see the 1 to n relation between the articles and the comments in a database diagram.

    • With a separate table you can choose whether you want to cascade deletes to the details table or not. If you don’t, you will not be able to delete an article as long as there are comments attached to it. This can be desirable, if you want to protect the comments from being deleted inadvertently.

    • 0