Allowing Multiple Values per entry?

[BenGD]

Hi, apologies in advance, I am at the bottom of the learning curve. I thought that I'd done reasonably well but then encountered a bit of an obstacle. Any pointers appreciated!

I have created a database from a starter solution (contact management) for a small series of events that I am developing.

I need to create something like a value list with a range of tags (for want of a better phrase) that I can apply to individuals in my database. I might need to apply one tag to one person and five to another.

What is best practice to be able to do this? I realise that when indexed it is likely that I will only be able to search on one tag at one time.

Thank you for looking.

Ben

[bruceR]

Sounds to me like you're just talking about a standard value list, checkbox-formatted. Your assumption about simultaneous searches for multiple values seems questionable, can you explain that?

[BenGD]

Hi Bruce

What I am trying to achieve is to be able to allot a range of different (sometimes multiple) tags to individuals within the database.

So one record might have x,a,& z attached to their profile and another b & x.

Plus I'd ideally like to have all the tags viewable in the record when in form view so if I search for all people that have tag 'a' in France I see that but can also see the additional tags allotted to the individual records in scrolling through the found set. Basic checkboxes are likely to be unmanageable on the page due to growth of the options as this develops.

Please ignore the additional search point that I made. It was both grammatically and logically poorly framed..

Edited July 19, 2010 by Guest

[bruceR]

Still haven't heard anything that rules out a standard checkbox field. What are we missing?

Edited July 20, 2010 by Guest

[BenGD]

Hi Bruce

The tags that I want to apply are potentially quite numerous. I will begin without about 25 and they could quite quickly expand to 50 or more.

I therefore assume (unless I'm missing a layout trick) that this would take up too much real estate on the database?

[LaRetta]

Hi Ben,

With 25-50 tags then I suggest you use a related table. Your method of viewing the tags could be portal or from the related table itself (either as list or summary report). Finding would be simple as well; multiple find requests for the tag type.

UPDATE: Also, in FileaMaker, we call them files with various tables within the file. Database really doesn't fit our terminology and it can be confusing as to whether you mean file or table.

DOUBLE-UPDATE: Oh! I didn't realize this was your first post! Welcome to FM Forums! :laugh2:

Edited July 20, 2010 by Guest

[comment]

Perhaps something like this might suit you:

http://fmforums.com/forum/showpost.php?post/333359/

However, you haven't explained what these tags are and what purpose they serve. It's quite possible you would be better served by a join table, with a record for each assigned tag - instead of lumping them all into a single checkbox field.

[BenGD]

Double thanks LaRetta I'll have a look at that option today.

I'll also learn a bit more appropriate terminology!

Edited July 20, 2010 by Guest

[BenGD]

However, you haven't explained what these tags are and what purpose they serve.

Hi comment

I am building a series of small scale events. The database consists of people who may be interested in attending one of these.

So the purpose of the tags for each name is to pinpoint the subject areas best suited to each person in the database.

As each event arises, I will be performing a find that allows me to draw out all those who have an 'x' tag, then I will omit those and do a find for all those who have a 'y' tag etc. Until I have reached the lowest priority category and have the marketing database best suited to that particular event.

Edited July 20, 2010 by Guest

[bruceR]

Hi Bruce

The tags that I want to apply are potentially quite numerous. I will begin without about 25 and they could quite quickly expand to 50 or more.

I therefore assume (unless I'm missing a layout trick) that this would take up too much real estate on the database?

That's not a very large number. Certainly you may have preferences on appearance. And some other, valid approaches have been mentioned. But a basic checkbox value list, properly sized, would still work.