script problem

[gaift]

i have made multiple scripts that do a modified version of find.

i have two layouts that will interact in this script,
one will have global fields (will serve as the search form)
and one will have the records with the actual data.

what will happen is the user will enter the name of an author,
my script will then go into a loop searching each record and if any of the records match it will set a field i have named "author found" = 1.
the if condition looks like as follows

if[table::author = table::global author]
set field[author found = 1]
end if

the problem i have is occassionally filemaker will not enter the if statement when infact author and author global are equal i have put dialogs in the if to see if it enters it or not as well as have a seperate layout to see if author and author global are the same, sometimes filemaker will enter the if statement and sometimes not when it should enter the if statement.

does anyone see the problem?
I have a similar problem with a key word search, file maker decides when it wants to work or not, ive written the logic plenty of times on paper and it will work sometimes and other times it wont.

 

[JeanW]

In fact you're by-passing the native find engine in FM.

It would be better to enter the data into a global, like you do, go in find mode in the right table (be sure to go to that table), set the appropriate field to the global and perform the find.
Be sure to uncheck the 'Restore' in the find window.
After that you can flag the records in the found set.

The key word to your problem is 'occassionally'.
Those are always hard to find.

Do you have the Advanced version ?
There you can use the script debugger in combination with the dataviewer to check each step of the script.

Also, which steps do you have before thescript should enter the if statement.
Is there a condition ?

 

[gaift]

i have multiple scripts running before the if condtition. this is one of a couple other scripts that limit my find.

but in this script the only condition previous to the conditional statements is setting a variable to loop through all the records, step after is just requesting to start at the first record.

I do have the advanced version and the debugger worked fine for my keywords problem but i still dont understand why in the debugger it shows as 1 at some points and shows up 0 in others for the author conditional statements, can it be the way i wrote up the calculation?

I am also unsure what you mean about unchecking hte restore in the find window

 

[JeanW]

Not knowing your total structure, it's a little bit hard to follow.

Obviously you don't go into Find mode, delete/erase my uncheck thingky.
You're looping trough all the records, flag the records equal the global value....and then ?

As far as I can see, I think that your script is acting sometimes on the 'wrong' table occurence, hence the 0 in the dataviewer.

Make sure each scriptstep is always acting on the right table.

 

[gaift]

after i flag the record, i perform a find on that flag, although im asked to expand the search options which will make my find script a lot larger, they will all follow the same thing.

flag records with all the matching fields, say an author, date and keywords, a script for the author like i previoiusly explained put an "author flag" if author matches the global field, similar idea for the date, and similar idea for keywords, i have the keywords working fine but now they want to expand with multiple fields, so the search in general is going to be a perform find/replace step in a script and it will perform a find based on the flags.

 

[JeanW]

What if you go relational.

The user sets the choice in a global field (or more than one) and you show the related records in a portal.

From that portal the user could go to each single record, back to the portal for an other one.

To hold the found set from the portal, you can make a general GTRR (GoToRelatedRecord) to have the complete found set.

This way you can make every possible combination and avoid the looping script and hard coding the needed data.

 

[gaift]

ok ill try this, however im not to familiar with portals and relationships, i am more comfortable with the hard coding being i am a computer engineer and not a filemaker professional.

So i would need two tables to perform this task? one that actually holds the records the other as the find form? currently everything is contained in one table.

also i had a question that doesnt involve this script, i created a new database that would just have buttons to open other filemaker databases, a database index i guess you could call it, most of the databases i have created ask for a user account when opening it directly, however when i click on the button on this database index it does not ask the user for an account and password i believe it just opens
the file as the admin as default, how can i get filemaker to ask the user for an account and password when opening via database index?

thanks for the help, its greatly appreciated.

 

[JeanW]

Then I would take a closer look to the use of relationships and portals.
You will have more flexible and more dynamic applications.
Also, when whatever change has to be done for whatever reason, it-s easier to do than looking up the possible places where you hardcoded items.

With relationships and portals, you can make searches in fractions of seconds. Just change the value of the related field and the portal will show the matching values.
From a line in the portal the user can go to every record.
Searches and flagging are two clicks away...

For searches; I never let my users search through the FM Find mode. All my searches are scripted.
It's impossible that a user has to search on every field in an input screen. This will need all the fields to be indexed.
I redirect the user to a special searchlayout, where specific, according to the requirements, fields are where to search on.
With 3 scripts the user can make a search, omit records, add search request, remove search requests etc. From there I take the user to a list layout with records if the found set is more than 1, or directly to the input screen if the found set is 1.

As for you opening script. FM will open all the related files with the same privileges, if there are, as the first already open file.
If you open the first file wih admin rights, all the related files will open with admin rights, without prompting the user.
With now the possibility to have several tables in 1 file this problem is nearly history. You just need to have user privileges.
If you have to open several files, make sure to work with groups with restricted access privileges and only open the files at admin (or full access) for developers level.
The files will open without prompting if the same password account resides in all the files.
Be aware that opening files like that will not activate a possible script at opening.
For this you have to call the file from a not related layout by script.

HTH

 

[Schlogg]

gaift,
Going back to your original problem, even though JeanW is right about using relationships, etc.
My bet is that some of your author names have extra spaces in them. This will muck up an "=" test.
"FRED " = "FRED" --> False
However, doing a find on "FRED" will find both "FRED" and "FRED ".

Cheers,
Paul J.