Customer list slow to populate

qleave

Hi,
We are having an issue with performance, that seems to be limited to certain users.
We have a form that uses the Customer table and from here to populate one of the fields you can choose from a picklist. The picklist opens the Customer table with a single filter turned on to clear out some non-relevant records.
The issue is when the picklist populates for certain users this can take up to a minute just to fill out the details on the picklist screen (often the whole screen freezes up, other times you can see the list slowly populating with details), whereas for other users it happens within a few seconds. I have checked filters and so on and they are all the same between users, so I can't see a reason as to why this would happen.
Extra system info:
Nav Version - 4.0 SP1
SQL - 2000
Any ideas on where to look for possible issues would be much appreciated.
Thanks

ara3n

use query profiler and see what sql statements are sent between the different users and which statements take long.

Do the user have the same permission?

In sql you can add additional security filters at record level.

qleave

Thanks for the suggestions. The queries sent are the same. In regards to the permissions some have higher permissions and some have less, but even people with the same permission levels are having different wait times (some wait a few seconds, others wait a few minutes). The PC's are exactly the same and the client setup is all standard.

kriki

Are you doing a regular indexrebuild and calculate statistics on SQL?

kapamarou

In such cases most of the times hiding some or all of the flowfields from the form will help. Depending an keys and amount of data, flofields might be extremely slow to calculate. Maybe the users that don't face this problem have hidden the flowfields. Otherwise check if there is any slow code on the form that executes for each record or field shown.

jannestig

IF it is only particular users having this problem and others are ok have you looked at the following scenario.

If the 'Slow users' have different terminals to the 'Fast users' have you had them login into these slow terminals and see if they are still affected by
the slow form load? and vice versa slow on fast terminal etc

If you can seperate outsomething like this you may find its not the code at all.

You can also create a new user who just access this form or warehouse, r u using scanners at all or handhelds?

qleave

Thanks for all the suggestions. In regards to the terminals I have had different users log onto different PC's and the problem only seems to be linked to the user, as they all have the same PC build and mine (as the admin) is even faster yet I face the same issue, with the slow list populate.
We are using scanners here for some of the form data entry, how would that affect things?
I will attempt to hide a few of the flowfields and see if this helps in the search time.
In regards to regular index rebuilds and calculate stats, we haven't done this, I was mainly trying to use the Navision optimisation step on the table, but this seemed to have no real effect on retreive times.
Thanks again

jannestig

maybe the solution is as simple as crapping the old users Login and Id etc and recreate them based on users IDS that don't have the issue?

It doesn't identify the cause i know but if it resolves the issue your client is happy. you could just create a test user based off a user who has no issue
and ask a slow user to use this one

qleave

I have now done a full reindex on the table via sql and that didn't help.
I also checked all the flowfilters and there isn't any that are turned on when returning the list for either sets of users.
I also setup a new test account and gave it the same permissions as one of the "fast" users, yet when I use this test a/c it is one of the "slow" ones and takes around 30 seconds to retreive the list.
Thanks again for all the suggestions.

kapamarou

Have you investigated the code that executes? Maybe there is something hiding there.

qleave

Thanks again everyone for your suggestions, in the end it turned out to be something quite simple. The issue was the number of columns that people had showing. The "faster" ones had at some stage hidden columns, when I did this on the slower ones (as they had about 18 columns, whereas the other ones only had around 9) it sped the searches and list population up greatly. So thanks again and sorry that I hadn't check this simple idea earlier.