Very slow display of related data in table views

Classic Servoy
1

Servoy 3.0 and 3.1

When loading a set of records, even in localhost, I see related data (e.g. customer data when showing a list of offers) load with a significant delay, even on small lists.

Any suggestion?

Thanks

2

Hi Ric

Are you seeing this in Developer or Client/Server?

I occasionally get a short ‘freeze’ or very slow data loading after working for a time in Developer but have always been able to clear it by re-starting Servoy. Not had any problems with Server.

GrahamG

3

grahamg:
Hi Ric

Are you seeing this in Developer or Client/Server?

I occasionally get a short ‘freeze’ or very slow data loading after working for a time in Developer but have always been able to clear it by re-starting Servoy. Not had any problems with Server.

Ciao, Graham

in Developer is definitely more evident, but I see this on client, too.
The list is loaded immediately, but the field showing related data come later (and I’m talking of 20/30 records on a MacBook Pro 2 GHz)

4

I’m talking of 20/30 records on a MacBook Pro 2 GHz

So anything more than about 3 nano-seconds is verrrry slow.

How about problems with Calculations field or Relationships? OSX always seems less forgiving than Windows if a Calc isn’t quite right - ie referencing an empty field.

Is this solution small enough to email across & I could test as have same MacBook Pro?

Regards

Graham

5

I have seen this problem many times (on Windows). What happens in my case is that all records are there, but the calc fields are empty. If you click on a specific field, that field’s content appears. After quite a while (up to 1 minute), everything appears. During that one minute CPU load is usually close to 100%. I can say that it is not a matter of errors in the calculations. I have discussed / reported this with Servoy a few times and many improvements on this have been implemented. I have not seen this recently on Servoy 2.2.7, but I don’t know that well about Servoy 3. Anyway, the issue in general is known. It is very disturbing, because your user simply thinks that these fields are really empty (“customer has no sales” or whatever it is).

6

grahamg:

I’m talking of 20/30 records on a MacBook Pro 2 GHz

So anything more than about 3 nano-seconds is verrrry slow.

How about problems with Calculations field or Relationships? OSX always seems less forgiving than Windows if a Calc isn’t quite right - ie referencing an empty field.

Simple orders_to_customer relation and a summary that returns the sum of order_items.
I’m also using a slightly modified rowBGcalc (not only even/odd rows, but also Active and Marked orders.
That’s all.
It takes 4/5 seconds. And customer and totals arrive quite after “resident” data.

grahamg:
Is this solution small enough to email across & I could test as have same MacBook Pro?

I’ll see if I can arrange a test.
In any case, thanks for your offer :-)

7

patrick:
It is very disturbing, because your user simply thinks that these fields are really empty (“customer has no sales” or whatever it is).

Do you also experience problems in refreshing aggregate values referring to stored calcs?
I often see no refresh, even if fields are showing in the form (the only way seems to do something in the foundset)

8

grahamg:

I’m talking of 20/30 records on a MacBook Pro 2 GHz

So anything more than about 3 nano-seconds is verrrry slow.

Found the responsible: a related field showing aggregate data (the total of confirmed items offer).
With the field, it takes 4 seconds to load a list of 20 records.
Without the field, the loading is instantaneous.

The strange thing is that the total field also slows down the loading of another related field (company name) coming from another table.
In absence of the total field, this field is loaded immediately, as the other.

9

Riccardino:
Found the responsible: a related field showing aggregate data (the total of confirmed items offer).
With the field, it takes 4 seconds to load a list of 20 records.
Without the field, the loading is instantaneous.

Found the solution: one of the tables involved in the process was dropped some time ago and I didn’t recreate the indexes.

A session with Index Consultant solved the problem.