Is there any performance issue if I use button bar to display a calculation result in list view?

Questions
1

Hi, I am curious is there any performance issue if I use a button bar to display data.

For example,
From Date A ~ Date B on the list view, where Date A and Date B are date fields. Overall, a text result will return.

When the solution grows(many records on the layout), will it slow down when the user goes to this layout when compared to the unstored calculation field?

1 Like
2

Hi Sam

The performance will follow the same rules as if you were using an unstored calculation field; the more complex the calculation the bigger hit on performance.

I would imagine the example you've provided would hardly have any impact at all. However, for instance, do not try to use ExecuteSQL for this purpose.

Regards
Andy

3 Likes
3

This is one dirty trick I started to use to build formulas in the primary file for not have to change the user data file (my way of Data Separation).
I started to use this even with 'Let' Functions with multiple Execute SQL processes.

2 Likes
4

Dark arts... :broom:

5

So is it better to create a field for display purpose or using merge field(with combination of hide calculation for empty values of Date A and Date B)?

6

I got a major slowdown with this. I was using a few buttons on “dashboard” page of the solution which were showing how many complaints remained to process in each category. Clicking the button would bring up the corresponding found set.

2 Likes
7

Personally, I always use merge fields amongst text, but it is down to personal preference. It all comes down to the overhead of the calculation itself.

3 Likes
8

I'm not sure if we do the same:
I have no scripts associated to the button at all. I use only the formula editor for the label to show a result you would usually build with a conventional formula field.
Let's say you want a "field" to represent a complete address. The formula for the label could then look like:
MyTable::Sex & " " & MyTable::Name & " " & MyTable::Surname & ¶ & MyTable::Street …

9

Yep this is fine. I understood that you use Execute SQL

I was doing the following calculation for the button labels:

"To request more info (" & ExecuteSQL() & ")"
"CRTC jurisdiction (" & ExecuteSQL() & ")"
"Qualified (" & ExecuteSQL() & ")"

2 Likes
10

I love @AndyHibbs's reply, and I think it is spot-on.

I have used the button-bar-to-display-a-calc technique, even pushing the envelope a little bit, and never with any performance hit.

The guidelines that I have always used have been pretty much implied by what Andy has said:

  • I stay very aware that I am doing the equivalent of writing an unstored calculation, and as such, I stay away from anything that would require pulling additional data across the network in order to evaluate. (This would include the use of ExecuteSQL.)

  • If the data is already stored in the local record which I know has been pulled to the client, I use it without reservation.

  • If I need to do some simple manipulations with that data that is already stored in the same record, I don't hesitate to do so.

  • Even if I need to compare that data against something that is stored in a global variable or global field, I will allow myself to do so, but I will stay mindful of two things:

    • How intensive the comparison operation will be.
    • How many records I expect to be displayed at any given time.

I've posted an example of a couple of the ways that I've worked with this technique:

Here is a screen-shot of a layout that uses various button-bar calculations for some enhanced list-view layout features:

ButtonBarList
ButtonBarList1560Ă—1010 157 KB

A brief video showing this layout in action can be viewed here.

Hope this helps.

Kind regards,

-steve

4 Likes