(Newbie?) Making User Defined Fields

[Totes]

Greetings,

Ok, so I am sitting here slinging out tables and fields, in what I like to call a database-a-palooza. Onlookers can only stare in amazement with their jaws slack and agape at the many marvels I bring forth in FM8.

And now back to reality…I am working on a db and all is well, I have reports, I have relationships, I have portals…then I decide I need a “User Defined” field and then it hits me or I have gone completely dumb…I have no idea as to where to start to set up a user defined field.

On the db there is a list of about 20-30 known items on the list, and I wanted to add 5 or so “User Defined” fields but I am lost. Do I need to set them up as globals? I really do not have a clue as to the process.

Could someone take a moment and point me in the right direction?

Thanks again for taking the time to help a FM newbie.

Jim

Edited August 24, 2006 by Guest

[T-Square]

Jim--

You're not dumb. You're not finding this because it's not there.

FM (and most DBMS, for that matter) is predicated on the assumption that the developer is going to identify the entities and attributes that will be needed in the solution and create those entities and attributes in advance. The idea of allowing more attributes later goes counter to that assumption.

Furthermore, it is my opinion that the contents of a given field are less important than how those contents are used by the application. (I might even call this the difference between "data" and "information"). Therefore, if you add a new field, its true value only becomes clear once you use it to derive functionality--by using it in scripts or reports. Your users aren't likely to be digging around there, so to my mind, the data is not being turned into information and isn't ultimately useful. I will note that one aspect of functionality--searching--is one that end users manage on their own, and there is a limited value to be gleaned from this use.

Most of the times that I have thought I needed user defined fields, I have found that I could accomplish the task without them.

There was a (LOOOOONG) thread in the Left Brain forum in which there was a discussion of the benefits of a Single Table structure, which in essence is the issue you raise here.

HTH,

David

[Ender]

On one extreme, you could setup a series of generic fields, "Field1", "Field2", etc. On the other extreme, you could define the fields relationally, using a table to hold the field names and another (join) table to hold the record-field value pairs.

Neither of these is a very good solution, however, as they would require some work to get field type issues resolved with numbers, dates, and times, and they don't really treat the fields with the individuality they deserve. What I mean is that most fields have a very specific purpose. Their data-entry is in a specific place in a specific layout based on the business's processes, and they are often used for specifc Finds or Reports, and placed in a specific place on each printout or report.

In my opinion, it's better to only define fields that have a specific purpose and place. Anything else is detritus waiting to happen.

If you still need this type of functionality, I hope you consider the relational idea over the generic field idea, as that at least has some sense of normalization.

[Totes]

Thank you both for the information...I sat around today for about 2 hours poking away attempting to create a user defined filed.

I wish I had written this earlier...oh well we live and sometimes learn.

Again, I do appreciate the help.

Jim