Windows: XP
FMPro: v6.04
----------------------
I've searched and couldn't find anything on this in particular, so I'm
hoping someone in the community can help...

I have a report based on two search criteria that the user specifies,
project and project version. Sometimes the user wants a report
specific for a project version, other times, they want to know
everything that has been written up against the project, regardless of
version.

Is it possible to direct in the script a different layout that is used
for the report based on the validity of the Project version.

I've tried the following simple entry:

If (Status (CurrentFieldChoice) = "")
Go to Layout A
else
Go to Layout B


I've also tried using

If (not IsValid(project version)
Go to Layout A
else
Go to Layout B

Neither of these are working.

Is there a way to make this script work, and why, in my simplistic
thinking, is what I tried not working. Thanks to all who help in
advance. I really appreciate all the knowledge that I've gathered from
help on this group.

- Teresa K.

Teresa K. wrote on (11/3/2005):



Script 1. What is Status (CurrentFieldChoice) ? I can't find that function
anywhere.

Status ( CurrentMessageChoice ), perhaps?

I don't know what your message consists of, but your problem may have
something to do with the fact that the function will always return 1, 2 or
3, according to which of three possible buttons is clicked (as described
in Help). I cannot return a null value. Your script would result in always
going to Layout B.

Script 2. "The validity of the project version" means what?

I assume you mean that it is an existing project, properly recorded in the
database?

The IsValid function tests whether the contents of a field are valid: a
number in a number field is valid, but text isn't. A date in a date field
is valid, but a number isn't (also described in Help). It doesn't know or
care whether the project version is, by whatever your definition, valid.

Matt

In article <xOwaf.4176$1u3.3471@trndny05>, "Matt Wills" <I'm (AT) Witz (DOT) end> wrote:


I use the IsValid function quite a bit when I need to test for the
presence or absence of a matching record in a related file. If I have two
files related by KeyField, and I don't know whether or not a record in
FileA has a match in FileB (both files add & subtract records by the
hundreds all the time), then my scripts do:

If ( IsValid(FileB_Relationship::KeyField) )
Do something
Else
Do something else
EndIf

I used to use calc fields that would have a one or zero if there was a
record match, then test for the presence or absence of a one. But it
seems to speed things up using IsValid instead.

I stumbled on this by accident and have never seen IsValid discussed being
used in this way. It's been working in many apps for quite a while (FM6,
served, multi-platform). Anyone know if there is some kind of hidden
danger in doing this?

Steve Brown

I seem to have seen other posts saying that rather than using 'IsValid'
one should use 'IsEmpty'. I don't recall the rationale, though.
Then the script looks like :
If( IsEmpty(FileB_Relationship::Constant), "Link 'B' broken", "")
where 'Constant = 1' for example.
Remi-Noel


<eyebrown (AT) mindspring (DOT) com> a écrit dans le message de news:
eyebrown-0411050723330001 (AT) 216-1...nk.wispnet.net...

Thanks Matt, Steve and Remi.

Remi, I also remember reading about using "IsEmpty" or using "not
IsEmpty" instead of IsValid, something about IsValid taking a wider
swipe at what would be included in a find (I think Lynn Allen was the
one that pointed it out..

"As for IsValid, it can fail if you have a relationship based
on mismatched field types, or for several other reasons,
because basically IsValid is intended to check for fields
that require a data type with a specific format (date, time, etc.)
or to validate if a field is missing. It is not intended to
validate RELATIONSHIPS."

But I digress, I think I need to take a different approach. The Status
function won't work [and yes Matt, Status (CurrentFieldChoice) is a
valid function in V6.0, but upon further research it is not what I
want].

I see the need for a self relationship, and am going to use the Control
number assigned to each record (it's a unique serial number generated
when a new record is entered).

And for clarity purposes, in this database we have multiple project
names, and the projects have versions assigned to them, i.e., Field 1
is named Project, and Field 2 is named ProjectVersion. The database
collects problem reports on each of the projects and has uniquely
assigned control numbers for each problem report.

Example
------------

Project ProjVersion ProblemReportNum ProjectAndVersion
----------- ------------ ----------------- -----------------
Dogs 1.0 abc-111 Dogs1.0
Dogs 1.0 abc-112 Dogs1.0
Dogs 1.1 abc-113 Dogs1.0
Dogs abc-101 Dogs
Cats 2.0 xyz-777 Cats2.0
Cats 2.0 xyz-779 Cats2.0
Cats 2.4 zzz-000 Cats2.4
Cats yyy-001 Cats

As you can see, most of the time, the user enters in the ProjVersion
number, sometimes they don't. My field called ProjectAndVersion is a
calculation with a text result based on [Project Name & " " &
ProjVersion]. The reports I have made would take them to two different
layouts based on the following:

Report 1
User specifies Project and a Version Number in their find request
Result: Go to Layout-A

Report 2
User specifies Project, but not a Version Number (they want to see
everything outstanding against a project)
Result: Go to Layout-B

That's why I was thinking I needed a validation, but I don't know
anymore...

Each layout in their respective reports gives different pertinent
information that the user needs. Maybe I need to use a global here but
how, I don't know... (and yes, I have to admit I'm a dunce when it
comes to using them, I wish I had a place to go to really get a true
understanding of using them, I know it would make my life so much
easier!)

Again, my sincere thanks for your help and explanations!

- Teresa K.

Teresa K. wrote on (11/4/2005):

I have to wonder why I can't find it in mine, neither Winduhs nor Mac.
It's not listed under Status Functions in Help, nor in the Specify
Calculation dialog, nor in the book.

Just in case, though, I tried to do a calc using it entered manually and
got an error telling me that it is not a recognized status flag.

Matt

Geez zip... Mea Culpa!!! Let's see...

Step one, re-read what I typed
Step two, re-read what's in my script
Step three, realize I made a huge blunder and then made it again
Step four, find a crow and prepare for dinner... followed by
foot-in-mouth for dessert.

How about Status(CurrentFieldContents) as the script step?

Mea Culpa, hope the weekend goes better than this.

- Teresa

Teresa K. wrote on (11/4/2005):

Been there, done that, must have enjoyed the pain. Still do it.

Crow, by the way, goes nicely with a side of broccoli sauteed with garlic
in olive oil.

Matt

In article <1131118268.480046.84510 (AT) g14g2000cwa (DOT) googlegroups.com>, "Teresa
K." <teresa.kabourek (AT) ngc (DOT) com> wrote:

Now you've got me worried. I think I stopped using IsEmpty because I
found it would fail with some kinds of fields. That is, if asked to
evaluate whether or not a field in a related record was empty or not,
should the record itself not be present, the field wouldn't be "empty," it
would simply not be there.

Also, when using IsEmpty to check whether or not a related record exists,
if the field being checked was empty, it would register, when what you
wanted to know was whether or not the record itself exists, regardless of
any field contents.

Checking the key field should work, as there should always be something
there. But I get all kinds of oddball data to clean up. You know users
....

A typical example of what I might use it for is to get emailed a .csv file
of some data. I import this file into a quickie ad hoc FM db, then relate
this db to my main db. Now I need to check what records exist in the new
file not in the main db. Sometimes I need to check the other way, what
records exist in main db not in new import file. IsValid has been doing
this job, for me, better than IsEmpty.

Steve Brown

eyebrown (AT) mindspring (DOT) com wrote on (11/5/2005):

I tend to use a somewhat less elegant, but, it seems to me, in light of
this discussion, more dependable method.

A calc tests whether a related record exists:

If ( This_Table::ID = That_Table::ID ) ; 1 ; 0 )

Sometimes brute force is necessary.

Matt