1 of 1 people found this helpful
you probably want to use field validation by calculation.
For the field that needs to be filled out certain member types define something like
Member Type = "volunteer";
not isempty (self);
this will always return a 1 (TRUE) if that specific member type is not selected, but if it is, it will return 0 (FALSE) when the field is empty which will prompt the user to put somehting in it.
Just in case:
Field validation is defined in the Manage Database dialog, validation tab in the field options.
Sounds like you are using multiple fields where it would be better to use a set of related records.
I don't think I am(?). I have a field for "membership-type" for each record and a field for "paid date/type." If an entry is made for a particular "membership-type" I want to require an entry in the appropriate "paid date/type" field.
What has really got me stumped is portals, mentioned in my recent post. Add to that I have a working portal elsewhere in my layout that I thought was working. It displays old records fine, getting them from a related table, but when I enter a new record is randomly populates the first line with data.
I feel like I owe you a dinner or at least a lunch already, but any suggestions would be appreciated. I've been reading and watching videos on portals, even dynamic filtering, but I'm at a loss so far. There's something basic that I'm missing.
If an entry is made for a particular "membership-type" I want to require an entry in the appropriate "paid date/type" field.
Don't see why you would need more than one paid date field and one type field. That's what suggested the possibility that you have multiple fields, a set for each type, when you would use a set of records in a related table instead. Note that i said "looks like" as you've said very little about the design of your database here and that limits everyone's ability to help you.
In your other thread on a portal, I've posted a down load link to a teaching file that includes several examples of search portals. It even includes a way on the intro layout for you to "buy me dinner" if you really want to as this file is a form of something I refer to as "geek busking"....
The records were related--incorrectly. Realizing that solved this and my portal issues
I tried it, and the logic makes sense to me, but it doesn't prevent a save-record command.
Here is what I used in the validation calculation for "FullStartDate" which lives in a related table. :
Members::MemberType = "Full" or
not IsEmpty (FullStartDate);
I have a save button above the field for FullStartDate so I know the record has been created with the MemberType field recorded when the screen returns to the original layout, but then there is no prompt to enter the FullStartDate when leaving the now-existing record.
Phil answered your question and you marked it correct.
It is still correct.
If you are doing something else - then stop.
Allow me to describe the DB further.
Members can be in five sub-categories.
I have a TO for members as well as as a separate TO for each sub-category. The Associate member TO, for example, stores starting date, paid date and other data relevant only to Associates. Ditto for Full members in the Full members TO, and the others in their respective TO. All tables are related by the layout's TO called Members, which has data relevant to all members regardless of sub-category. The tables are related by a MemberID. The sub-category TOs store the fact that a member is or was ever a member in that sub-category and the last time he started in that sub-category--even though his present membership status might not be of that sub-category.
When I view my layout for a member based on the member TO (which shows all members from all categories), I have on the layout the related data from the sub-category he's ever been a member of: start date, and paid date. (Members move among categories over time.) What I want is for this layout to require <not IS EMPTY> in the start date and paid date fields (which live in the related tables) for the members current membership status. Membership status lives in the layout TO, Members.
Sorry but I can't fully follow that description. You appear to be confusing "table" with "TO" (table occurrence). They are not the same thing.
1 of 1 people found this helpful
I thought I already mentioned a few of the following ideas to you but I can't find the comment.
There are a lot of things you're doing here that make it very difficult to help you.
For example: over-use of the term "TO" without meaningful detail or names behind it.
Talking about the relationship between to table occurrences as if THAT is the TO.
Scripting and navigation do not go to TOs.
They go to LAYOUTS; and the layout is based on named table occurrence.
No, membership status does NOT live in "the layout TO Members".
It would be a lot easier if you could upload a clone of your file.
If you can't do that, then go to the effort of building a simplified version and upload that.
Or add more screenshots including the relationship graph.
Let me try it again:
Members can be in five sub-categories.
I have a table for members as well as as
a separate table for each sub-category.
The Associate member table, for example, stores starting date, paid date and other data relevant only to Associates. Ditto for Full members in the Full members table, and the others in their respective tables. All tables are related by the key field, MemberID. The sub-category tables store the fact that a member is or was ever a member in that sub-category and the last time he started in that sub-category--even though his present membership status might not be of that sub-category.
When I view my layout for a member based on the member table (which shows all members from all categories), I have, on the layout, fields from the related tables of sub-categories: sub-categoryStart date, and subcategoryPaid date. (Members move among categories over time.) What I want is for this members layout to require <not IS EMPTY> in the related subcategoryStart date and related subcategoryPaid date fields for the members current membership status. This is so a user cannot enter/modify the membership field to "Full" for instance in the layout's field for membership type and leave the record without making sure that there exists an entry in the related table's subcategory field, FullPaidDate.
is the actual data really different for each subcategory? I see for example, that both associate and full members have a paid date. Do the other fields in these tables match up or nearly so?
And is the change in membership type always in a predictable pattern?
The Associate member table, for example, stores starting date, paid date and other data relevant only to Associates.
What kind of specialized data; exactly?
I am going to propose that NONE of these dedicated tables need to exist.
Example file shortly.
Sounds like all membership levels have a start date; and a fee based on current pricing for that membership level.
Question about the end date. Is it actually necessary and is it meaningful?
What if I have been member level 2 for the last year. What if I enter an end date into the member level 2 record?
Lets's say I filled in the end date two months ago.
Now what am I?
Not a member?
Always a level 2 member until I pay the fee and set start date in the member level 3 field?
Can I move up and down in the member-level hierarchy?
Or really; only in one direction? (similar to Phil's question)
It would really help if you can be much more detailed in your description.