FM6 - 7 migration - problems with lookups

#1

There seems to be an issue with lookups as they are sometimes dreadfully
slow (inconsistently)

Post conversion to 7 a script creating a new record with 4 simple
lookups defined takes 15-20 seconds to run on a Pentium 4.

Removing the lookups in field definitions and scripting it with 5 simple
setfields: e.g. set field (somefield, relatedrecord:somefield)

Runs in <1 second.

For example:

script1:

new record
set field somekey, some global value
.... triggers 4 lookups...

The 2nd script step takes 15-20 seconds to complete in script debugger.

script2:

new record
set field somekey, some gobal value
# former lookups...
set field ..., some related value1
....
set field ..., some reaated value4

gets the same job done in under 1 second.

What's actual the source of the problem?? Interestingly its not
affecting every lookup, just some of them. Both the files that the new
record is in, and that the lookups are from are quite large (hundreds of
thousands of records) and are part of a typical FM6 architecture... (30
plus files).

---

On an unrelated note regarding 'best practices'... can anyone offer any
reason why I wouldn't want to define globals in their own tables, or
even define globals that are only used in one (complex) script in its
own table named after the script. It seems a nice way of partitioning
them a bit, reducing clutter in the main table(s), and so forth.
Are there any disadvantages I haven't realized?

thanks,
Dave

#2

FP wrote:

Quote:

The only problem I've come accross with having globals in a table of
their own is forgetting to go to a layout displaying records from that
table when going to related records.

Eg. assume you have a table "Globals" with field "Go To RR IDs". You
set the field to a bunch of company IDs then want to go to those
related records. You must first go to the "Globals All Fields" layout
otherwise going to related records won't work.

As simple as this sounds it has cost me atleast 10h of bug tracking.

Or likewise, if you are using a global to hold a selected record ID, and

you want to use that global to display the proper records in a portal,
that global must live in the table that is behind the table occurence
that is behind the layout.

#3

In article <11geooghu978m2c (AT) corp (DOT) supernews.com>,
howard (AT) nospahm (DOT) fmprosolutions.com says...

Quote:

FP wrote:
The only problem I've come accross with having globals in a table of
their own is forgetting to go to a layout displaying records from that
table when going to related records.

Eg. assume you have a table "Globals" with field "Go To RR IDs". You
set the field to a bunch of company IDs then want to go to those
related records. You must first go to the "Globals All Fields" layout
otherwise going to related records won't work.

As simple as this sounds it has cost me atleast 10h of bug tracking.

Or likewise, if you are using a global to hold a selected record ID, and
you want to use that global to display the proper records in a portal,
that global must live in the table that is behind the table occurence
that is behind the layout.

Thanks for the tip; undoubtably saved me some bug tracking, and ensured
that I put the globals that need to be in the main table there.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

FM6 - 7 migration - problems with lookups

comp.databases.filemaker comp.databases.filemaker

FM6 - 7 migration - problems with lookups - 08-19-2005 , 03:37 PM

Re: FM6 - 7 migration - problems with lookups - 08-20-2005 , 12:08 PM

Re: FM6 - 7 migration - problems with lookups - 08-20-2005 , 02:21 PM