return error message when there are no valid relations??

[Norvin]

I'm using a relationship to perform a find based on a date range. How can I return a message in a script when there are no valid relations.

[LaRetta]

Hi Hagy,

I assume you mean before a GTRR to test that there are related records? Use any non-empty standard field from your related file. For instance, if there is a serial, script portion to use:

If [ IsEmpty(ChildTable::Serial) ]

Show Custom Dialog [ OK ; "No records found" ]

Exit Script

End If

LaRetta :wink2:

[T-Square]

Or, if you're scripting a search and want to capture no records found:

Set Error Capture [On]

Enter Find Mode

Set Field [YourField, yourCriteria]

Perform Find []

If [Get(LastError) = 401 /* No records found */ ]

Show Custom Dialog[ Crank; "Bummer, Dude"]

Exit Script

End If

[Søren Dyhr]

I assume you mean before a GTRR to test that there are related records? Use any non-empty standard field from your related file. For instance, if there is a serial, script portion to use

I can't help finding David Kaschel wise, when he says:

For every table you create, the first field in that table should always be a unique ID field. The best and only completely reliable way to do this is to create a number field that is auto-enter, serial number, incremented by one, cannot override. This will be the single most reliable and predictable method to identify and relate your records.

This means that a somewhat nearer to machinecode than either IsEmpty( ... IsValid( or Count( for that matter can be utilized, namely:

If [ 1 xor PortalStuff::portRecID ] 

     Show Custom Dialog [ Message: "No related exists!!!"; Buttons: “OK” ] 

Else 

      Go to Related Record [ From table: “PortalStuff”; Using layout: “PortalStuff” (PortalStuff) ] 

End If 

...since the portRecID is a integer!

--sd

[comment]

1 xor PortalStuff::portRecID

==

not PortalStuff::portRecID

One less evaluation to make (of the always-true 1), and much easier to read, I think?

[Norvin]

Thanks Guys.

[Søren Dyhr]

well 1 xor evaluate despite, the field is empty. So if an IF statement only looks for 1's and not 0's are you absolutely right!

A quick test seems to confirm it! Regarding the read-ability is it a matter of habit, I sprinkel my stuff with 1 xor- and 0 xor's and can spot them right away, opposed to where say not not somtimes disappears, and if I'm desiding to reverse the logic ...is it just first # I'll change, instead of rearranging the lines in the statement.

--sd