Forcing sort button on report

This might be a stupid question, but is there any way to force the Sort button to appear on a report request form? I have tried to compare a report that has a sort button and a report that doesn’t, but couldn’t find out what the difference is between the two. This concerns the sales order documents from the sales order card. Sometimes we print multiple records at the same time, and would like to sort them in a particular way.

The difference is quite simple. Whether or not the Sort button is displayed depends on the value of the property DataItemTableView on the dataitems. IF a key is selected, then the Sort button is NOT displyed, else it is displayed. Note however, that you can override the user’s sorting with a SETCURRENTKEY statement in the code. Also note that if you have more than one dataitems in a report, one of them may have the DataItemTableView key value set, and the other may have the property blank. In this case the sort button will appear on one of the pages in the requestform, but not on the other. Hope this helped you. Lars Strøm Valsted ------------------------- Software development today is a race between the programmers trying to make better and more foolproof programs, and the universe trying to make bigger idiots. So far the universe is winning.

Hello Torolf, Design the report with the missing ‘Sort’ & look at the properties of the affected dataitem. If you look at the DataItemTableView property & drill down in this field, you will find that a fixed key has been specified for this report. If you delete the fixed key, the sort button will return! Hope this is of assistance. -------------------------------- Edward Bloomfield Navision Support Consultant Cambridge Online Systems Limited www.cambridgeonline.net

Looks like Lars beat me to it… -------------------------------- Edward Bloomfield Navision Support Consultant Cambridge Online Systems Limited www.cambridgeonline.net

Torolf, re. sorting of the sales-order-like documents. If you need to sort headers, Lars and Edward covered that, but sorting lines on an order requires some more. Navision puts the records from the “Sales Line” table into a temporary table, and then prints records from there(performance considerations?? note to self - never attempt to figure out their logic, might blow a lid off). IMHO this makes the mod a little easier. In the last data item of a sales order report (Integer/Sales Line), before “WITH TempSalesLine DO” you could insert a SETCURRENTKEY that serves a purpose. If it needs to be user controlled, put an option on the request form. Alex

Thanks for the help. I think Alex’s suggestion will work best, since most users can’t decipher the sometimes complex key choices that appears, I can build it right in to the request form. Perhaps a new feature for Navision should be a Description field on keys.

Giving the user the ability to choose the sort is usually ok and “Master” type tables such as, Customer, Vendor, Item, etc. I larger databases “Secondary” tables such as Item Ledger, G/L Entry, etc. it can have significant performance issues. For example, let’s say I have a report that ususally is ran for a monthly period. To speed the report, I have the “Posting Date” high in the sort of a given key. Now the user chooses a different sort where “Posting Date” is either late in the key or worse not present at all. Another issue is that it is quite possible the user will forget to select a key; in this case the default sort is the primary key…not exactly the most efficiant key usually. Bill Benefiel Manager of Information Systems Overhead Door Company billb@ohdindy.com (317) 842-7444 ext 117

William makes a good point. A lot of the keys that are on some of these tables are not ideal, but are used by the system for specific purposes. We have already added plenty of keys to the Sales Order table, and I am reluctant to add more to accomodate some of my users requests. Anyone know what type of overhead is required by a key with Navision 2.6e on a SQL backend? I am going to implement the request form key choice option. That way, I can give my users an easy to understand choice of how they would like to sort the items, and I avoid keys that are totally useless or self-defeating to the users. Thanks for the help.

Overhead is minimal durring posting for a new key, in fact I have never really seen a difference. We have a 29 GB database. As to the Sales Orders in general, my company ususally has a great deal of open orders. I have a few reports with less than ideal keys and they still run reasonably fast. Bill Benefiel Manager of Information Systems Overhead Door Company billb@ohdindy.com (317) 842-7444 ext 117