I have a pop up list that is using a value list that is being pulled from a related table.

i.e. table is a list of creators and their subject area (some art, some architecture). In the main entry db (holds records for individual images) if an image is marked that the subject matter is art, the field for creator will pull a list from the table of all artists only. Right now there are about 4000 different creators.

So- when I click in the creator field in the main entry... it take sooo long for the list to appear.

Also, the database is being stored on our server.

Any ideas how I can speed up process?

Thanks much.

Is the database on a shared network volume, or a FM host. My bet is that it's a shared network volume.

This is a bad. bad way to share databases. it's slow (as you have discovered) and invariably corrupts the file over time, which is why FMI does not recommend it.

Copy the file to your local hard disk and delete all the other copies floating around. When the database is finished and you need to share it with other users, learn how to set up a dedicated FM host computer.

I am told that the server is running filemaker server 5.0... I think there are about another 100 databases running on the machine.

Any other ideas?

Thanks much.

Sukisue:

If you've got FileMaker Server running, ask if that's the only thing running on that server - if there are other applications/services running on that machine, then FM Server will not run at anything like its optimal speed - it should have its own dedicated machine.

Otherwise, are there any other features that run slowly, or just that one pop-up list?

-Stanley

Machine is dedicated...

All else seems to be running fine so far. Though, this is a new db to replace an old flat one- so main db has only some test data (45,000 records are soon to be imported) only tables actually have all their data.

I should've also mentioned that the list is only really slow the first time the field is selected (takes 1-4 minutes) after that it's just a bit slow (5-15 seconds).

Thanks again.

Based on which indexed key this related value list is being deployed ? What are the keys you're using ? Is the right key a plain text field or an ID ? Is it a calc or a text field ?

How many max records should appear in that list ?

If you are saying that you could have 4000 different items in your valuelist, then it is going to be slow no matter what. I would try to limit the number of values by adding a few constraints to the relationship. If nothing else, you could possibly break the list down alphabetically. IE., have one pop-up that selects the starting letter: A, B, C.... etc. and then a second popup that selects the actual creator that starts with the selected letter.

This is what is happening:

FM server sends data when and only there is an request for them.

So the first time the field with attached list is accessed, all necessary data are pulled down from server and the index (the list itself) is created.

So the latency when accessing the list for the first time is due to the indexing process.

If you accept the delay when opening the db than you could preload the list by means of startup script.

Something like this one:

Freeze Window

Go To Layout[the layout with the list]

Go To Field [select, the field with the list]

Go To layout [your startup layout]

...

..

Do some important init stuff

Dj

I have experienced this too - but mostly due to a slow line between our sites.

Make sure that the field being used for the list is NOT a calculation - this was the most dramatic difference I discovered. Make sure the field is indexed.

If it must be a calculation, then improve performance by making the field to be stored.

All points considered, 4000 items in the last is far too many, I don't think any one (human) can handle that size of list.

Hi all,

I've use a scripted 'Insert from index' in stead of a valuelist.

Though lots quicker, it has it's drawbacks as well:

- It does not scroll to the current value

- It capitalises all entries and does not display 'special' characters

- It's ugly as hell...

Ernst.