Empty fields

[Nattani]

Hi,

 

I want to find a way to economise on space in a layout where certain records have empty fields and others may not. Is there an 'if' function I can build that will direct the FIELD itself to remain absent if it is empty, not just operate the CONTENT of the field? And therefore allow the parts/other fields to contract into the space vacated?

 

The purpose of this database is to contain examination questions that link back to a vignette. There are several vignettes with sub-questions linked to them. Not every vignette has the same amount of data, and not every question has the same number of correct answers, where each answer is accommodated by a field. So, I am hoping to develop a flexible layout that will change the fields listed based on the presence/absence of content in each 'found' result.

 

Am I dreaming?

 

Thanks,

 

Nat.

[Maarten Witberg]

One way to do this is make separate tables (v7) or files (v5-5.5-6), one for vignettes, one for questions and one for answers. The questions can be related to the vignettes by the ID of the vignette; the answers to the questions by the ID of the question. Then use a portal in the vignettes file to display the related questions only.

 

Another way to deal with it is make a hierarchical file using parent and child records. This is only feasible if there are no doubles (no two vignettes have the same question).

 

A hierarchy can be built by adding the parent's record ID to a multikey field. You can then sort in a portal or sort the records themselves by this key.

In your case, there would be three levels (1=vignettes, 2=questions, 3=answers). The level would be counted based on the number of IDs in the multikey.

 

How you proceed, also depends on the way you want the users/students to enter the answers (once-off and then clear the fields or retain the results for future reference). Or make use of hardcopy.

 

Please post again if you need more help.

 

kjoe

[Leader]

You didn't mention if this is for interactive data entry or for printing. I assume you know you can use sliding fields for printing, and therefore you mean data entry.

 

I'd guess you would want to use a combination of layouts tailored for the number of fields. In other words, if you had only 3 fields, you'd use scripting to deploy the 3 field layout, and if you had 5 fields, you'd deploy the 5 field layout.

 

I don't think this following solution would work for you, but I had a medical data base which had fields that could vary wildly in amount of data in such fields as indications, contraindications, side effects, dosage, etc. I was lucky enough that I could construct a calc text field in which I concatenated and formatted the various fields. If I had had FM7, the job would have been even easier with all the extra formatting options.

[Marmot]

what is a "multikey field" and where do a I read about it?

 

marmot

[Maarten Witberg]

A multikey field is simply a text field that is used for storing a list of record IDs in. Usually to create a many-to-one relationship. Lists can look like this:

 

ID001

ID002

ID010

ID122

ID072

 

You can make a relationship between this field and the RecordID field. Any recordID that is in the list confirms the relationship. Adding ID's to the key should be scripted.

Note that you can use any kind of text string for this, e.g. a global field with a value list with multiple selections can be used for portal filtering.

 

I was hinting at another possible use of multikey and that is build hierarchies of records within the same file or table.

Say you have a parent record (some vignette) and you wanted to create a child record (which holds a question). The script would then append the parent's ID to the child's multikey. The multikey holds the record's own ID at record creation (using auto-enter).

So the parent's multi would hold for instance,

 

(vignette)

ID100

 

the child (question)

 

ID100

ID110

 

the child (answer)

ID100

ID110

ID120

 

Child (question 2) of the vignette would hold

 

ID100

ID130

 

etcetera.

 

Using PatternCount(multikey_field;"ID") you can link a record to a level, vignette, question or answer. and from there on to layouts and stuff. for instance, there would be only one text field that holds question, vignette name or answer. But a calc field would determine the field label:

case(cLevel=1;"vignette";cLevel=2;"question";"answer")

 

Sorting by the multikey field (either in list view or in a portal) will give you an ordering of vignettes-questions-answers. The order of the IDs in the multikey is crucial for the sort to work (parents above children).

So you need to use an intermediary field in the script:

 

Code:

---

set field[gTempKeychain, multikey_field]
new record/request
set field[multikey_field, gTempKeychain & "¶" & multikey_field ]

---

 

these are the basics. I hope I am making sense.

 

kjoe

"smirk"

[Marmot]

>

 

confirms? ...appears in the portal that shows a selection or found set ("portal filtering", in other words)..works as a kind of condition for inclusion...so one would make a relationship in relationship graph between the multikey field and an ID field in another table which serves as condition for inclusion in a portal in a particular layout

 

I've tried to follow the rest of your very interesting explanation..Do all the tables (parents, questions, answers) have to have id which is multikey..? Surely not..just the parents id is multikey (one-to-many)?

 

It's a very helpful explanation which I understand in part. I'll have to keep it in my head and keep coming back to fmcafé for more illumination

 

...I mean I really don't get the levels concept at all but suspect this all depends on a better grasp of the functions available in fm7

 

Thank you kjoe

 

marmot

[Maarten Witberg]

See if this sample helps you understand.

 

kjoe