Hi Alison

These are from my notes.  The property that we want to control is OrderByDesc.

//GridColBlock properties
// AllowOrderBy = true|false
// OrderByDesc = true|false
// CustomActionFile
// CustomIdField
// Alignment
// JumpEntity
// ShowHeading = true|false
// ShowSelectAsGif = true|false
// JumpAction
// JumpKey
// CreateScript
// Visible = true|false

myGridColBlock.AllowOrderBy = true;
myGridColBlock.OrderByDesc = false;
myGridColBlock.Alignment = "LEFT|RIGHT|CENTER";
myGridColBlock.ShowHeading = false;
myGridColBlock.ShowSelectAsGif = false;
myGridColBlock.JumpEntity= "Company|Person|Communication|Case|Address|Library|Notes";

I will get that sorted in the documentation.

Thanks

Hi

I know that this has been answered. I'm not a developer, but intrigued why design a table within an ASP page and not create a custom table within CRM and call on it in the ASP page?

Hi Matthew 

I don't know what Alison would say... but I think this is to do with asking dynamic questions when you don't necessarily know what the answer will be and how you want to display it.    I think there are two categories of use.

Firstly, the API allows you to create a list block without reference to metadata, you can then base it on any SQL query statement you want.  That SQL query can fetch the rows and columns you want and so will then need to add those columns to the grid.

Secondly, the API allows to adapt a meta data defined list by adding additional columns if the circumstances require it.   

The main reasons why I am building a list in this way are

1. When the asp page is deployed I don't then have to worry about creating lists and views in CRM itself, I just deploy the ASP page.
2. The metadata is kept tidy so if the ASP page is removed in the future then I also don't have to remove the list and / or view.  In my experience the more metadata you have in a CRM implementation the less efficient CRM runs.
3. It is often quicker when developing the ASP page to build and maintain the list in the ASP page rather then build the list in metadata and then reference it in the ASP page.
4. Everything is kept in one place so all changes are made in the code rather then having to make changes to the code and / or metadata.
5. Fields can be more easily added and / or removed from lists dynamically when they are fully maintained in the code

Also when building the list in the code it means that the list cannot be edited within CRM itself.  This can be a bad thing as it reduces flexibility but it can also be a good thing as it prevents lists being altered which should not be altered.   

I would flag a warning.  Coders tend to see everything as a coding problem. 

The design philosophy  of Sage CRM is to reduce the amount of code and where possible eliminate code.  Code has to be maintained and has to be updated and so requires coding skills.  What may be a cheap, quick and convenient way of implementing a solution may pass expense, delay and hassle to a project when it comes to upgrading or adapting a system when business needs change.

So there.