Form Sorting I thought it was simple!

MatStephensSandA

Hi smart people!

I have issues with the speed of my Native 2.6 Database which runs on Native 3.7 executable.

I am aware of the Native issues ie only one processor and only 1 GIG of RAM and so on....Also so telling me to upgrade to SQL is not a viable solution. [-X
Also bright sparks who tell me to improve the hardware are discouraged from replying lol.

In addition to a full code review in order to try to speed up our system I also face an issue in relation to opening forms.. On occasions the database can be extremely slow in responding to this basic command.

I know each form has the potential to be sorted using the SourceTableView property.
I also know that the RunFormView Property can be enabled on a trigger or menu item in order to run a form.

My question is what to do if these are in conflict with each other.

To labour the point...the forms in question have a property specified in the SourceTableView of the form itself for example
WHERE(Customer Own=CONST(Yes),Adjustment Type=CONST(Create Batch))
On the run form trigger the RunFormViewProperty of SORTING(Posted,Entered By) WHERE(Posted=CONST(No),Banding=CONST(No)) is stated

The base form sorting order wins out in terms of which sorting order is applied.
So my question is how do i make the trigger override the form default or can i not?

I have given it some thought and the best solution i could come up with is to have a duplicate of the forms in question with no sorting order specified however this action will double my number of forms.

Any help or advice will as always be welcomed.

Thanks
M@

mrsa

You can override default behavior of tableview for example if you write something like this:

Form - OnOpenForm()
Rec.SETCURRENTKEY("Document Type","Buy-from Vendor No.","No.");

or you can put some option variable on form and depending of choice set current key to different sorting and order.

Did you try to split native database into more database files on different phisical disks to get bether performance.

MatStephensSandA

Hi.
thanks for the responce and to answer the question yet the DB has been split onto different physical discs and different logical particians. The discarray is an 18 disc array set to Raid 1+0. The Hardware is a good as it is going to get without further investment, which is not an option.

I accept your suggestion but would this not further restrict the users? If the Key was coded at point of opening then the diversity of the form will be completely removed.

In my system i have many users who view the same form for different reasons. Each different view of the from will be triggered by a different menu item or a different button.
If user 1 usies trigger one to open a form and wishes to see the form by current stock and user 2 uses a different trigger to see the same form but sorted differently ie despatched stock.
My question is how to have a default sorting order on the form (for table look up reasons) but make the form sorting order also change depending upon the trigger that calls it.

As i said in my first post i thought this was achievable by the RunFormViewProperty of the trigger however this is not the case as SourceTableView takes priority.

I suspect i am stuffed however any ideas are welcome.

Thanks
Mat

kine

Basic problem is: The key must be in line with filters...

Question is: how to set the correct key based on selected filter?
Answer: there were posts about using RecordRef and KeyRef (but they are not working very well in 3.70 client) to find the correct key and set it dynamically. But it could be one solution for you.

But quickest solution is proper training for the users to select correct key when setting some filters (of course, situations, when filters are predefined in code are still problematic...)

DenSter

Why program the form to use a different sort order than what is in the form properties? Why not just change the form properties?

MatStephensSandA

DenSter wrote:

Why program the form to use a different sort order than what is in the form properties? Why not just change the form properties?

the form is not progrmed in terms of code it is configured in terms of form properties.
So our stock form is sorted by stock number as default.

WE have 150 users all using the same form for a variety different reasons.
They access the same form using many different menu items/buttons.
Not all references to the stock form are relevent to the stock number. for example if i want to allocate stock to production i do not want to see all the stock sorted in terms of the stock number i want to see it in terms of the item number.

The table is so big now that in order to open the form it takes a long time this is becasue the filters applied to fields at point of opening the form (from the trigger) are not in the fields in the default sorting order (as specified in the form properties) of the form properties.
In order to try to make this faster for the user i have tried to use the properties of the TRIGGER in order to make the sorting more dynamic. however this method of sorting is overridden by the form's properties.

Kine wrote:

But quickest solution is proper training for the users to select correct key when setting some filters (of course, situations, when filters are predefined in code are still problematic...)

This is the issue. The user does not have the option to set the filters. The point of having the seperate triggers to call the form for different reasons is that these filteres are passed without the users knowledge.

So we have a custom table that holds our entire stock (we are pre item lot tracking).
Option 1
When a Staff member wants to search the stock table for all current stock he looks at the default form as originally designed.
Option 2
When a factory employee is making a stock receipt he needs sees the same form but filtered in a different way.
Option 3
When a factory employee is selecting stock for despatch he needs the same form but filtered in a different way again.

If the default property of the form is set to sort by stock batch number then this helps the majority of the users as they are option 1. The idea is to have different triggers/menu items/buttons to call the same form with filtration applied (thereby requiring different sorting) to suit option 2 and option 3

The users can not specify this as they should be given the information relevent to them.

Its looking more and more like i will have to have a copy of the same form for each trigger but with seperate sorting.
That seems a but pants to me.

I cant be the only user in the world who has needed to open the same form with different filters on.. or maybe i am lol..
as alwyas thans for the info so far but i dont think im there yet

kine

Why the sorting is defined on the form? Just remove it it from there and it will not override your selection when calling the form (or use two forms, with and without the sorting defined in properties).

MatStephensSandA

kine wrote:

Why the sorting is defined on the form? Just remove it it from there and it will not override your selection when calling the form (or use two forms, with and without the sorting defined in properties).

Good question. I have made an assumption that the sorting order was specified for table lookups however this should use the primary key by default so maybe that is my solution.

I will test it.

Thanks.

DenSter

MatStephensSandA wrote:

In order to try to make this faster for the user i have tried to use the properties of the TRIGGER in order to make the sorting more dynamic. however this method of sorting is overridden by the form's properties.

What do you mean by TRIGGER? When I hear someone talk about a trigger in the context of NAV development I think of the C/AL editor.

It seem like you are calling the same form in different scenarios, and you want the place that calls the form to decide how to sort the data. In that case you need to remove the view properties of the form. You might want to consider creating a new form and leave the standard form for standard purposes.