Multiple Not IsEmpty

[steigrafx]

Is there a way to string together field names in a Not IsEmpty calculation instead of writing:

Not IsEmpty (field1) and Not IsEmpty (field2) and Not IsEmpty (field3) etc., etc.?

Or, in the alternative, is there a way to represent a range of consecutive fields such as Not IsEmpty (field1~field12)?

Thanks,

Kevin

[comment]

You can string together the contents of several fields, but =

not IsEmpty ( field1 & field2 )

is not the same thing as =

not IsEmpty ( field1 ) and not IsEmpty  (field2 )

It's actually the equivalent of =

not IsEmpty ( field1 ) or not IsEmpty  (field2 )

[steigrafx]

Thanks for the reply, comment.

I'm looking to test if consecutive fields are all empty. I have a report listing a number of names, all in consecutive fields. I'm trying to prevent the user from printing a blank document (button script). Sometimes a (dumbass) user will print the report and not bother to look at it, then put it in an envelope and mail it.

Of course I can string together a bunch of Not IfEmpty's, but I thought there might be an easier, more efficient way to do it.

Thanks,

Kevin

[comment]

What are "consecutive fields"? IMHO, if a field is not supposed to be empty, you should validate it as such. Then it's not possible to have a blank "document" (record?), let alone print it.

[steigrafx]

Hello again, comment. Actually, the fields may be empty. I only need the report to print if any of them, not necessarily all of them, are populated.

I certainly wasn't very clear on what I meant by "consecutive fields". What I meant was fields whose names are identical except for a distinguishing number. For example, Person_01, Person_02, Person_03, Person_04, etc. I thought maybe there was some sort of wild card to use in place of the number.

Thanks,

Kevin

[comment]

Ahm... If you have fields named Person_01, Person_02, Person_03, Person_04, etc. then you almost certainly have a structural problem. You should be using multiple records in a related table instead of multiple fields.

[steigrafx]

Not in this case. The database is used to keep track of conferences, hearings, and trials. It is simply a collection of witness and attorney names for a single event.

The "report" I mentioned is actually three layouts. The first one lists the details of the case (caption, file number, etc.), the second is a list of appearances (attorney names and addresses), and the third is just a list of witness names. These documents are sent to a transcription service along with an audio CD. The lists are for the convenience of the transcriber so that they have the correct spellings.

Sometimes conferences are with attorneys only. In that case, there are no witness names and I don't want the third page to print at all, since it would be blank.

Thanks,

Kevin

[comment]

If all you need is a list of witness names, why don't you enter them as a return-separated list into a single filed? Then it would be very easy to see there are no witnesses.

Of course, doing it this way is very limited. By living in a related table, each witness can have a set of attributes, e.g. first name, last name, address, etc. Your method would require 36 fields just for those 3.