Database fields and aoColumns order

prathap

Hi,

Many of my database queries return fields not in the order as it is being shown in grid. Since this is LIVE application and right now, we are changing our existing list using DataTable, we are finding it difficult to order the database fields and actual order required to be shown in grid.

Is there any option to write aoColumns array irrespective of the database fields order containing in the aaData array?

Point is we don't want to use aTargets option of aoColumnDefs as the fields and its order in the database query can be changed now and then.

Regards,
Prathap.

allan

aTargets can be targeted using a class. So you give a header cell a class and aTargets can pick that up - example: http://live.datatables.net/pinukes/1/edit

Is that the kind of thing you are looking for?

Allan

prathap

Hi Allan,

Thanks for your reply.

All my table headers have same class defined in common CSS. So i afraid, i cannot go for that.

But i tried with "mData" and now issues seems to be solved. In "mData" i mention the fieldname from database SP and in "sTitle" i mention the field header. So now, i can re-order columns irrespective of its order in the database.

My question is, since mData is object array, rather than array, will it slow the grid loading?

Regards,
Prathap.

allan

> All my table headers have same class defined in common CSS.

You could have multiple classes for each column, or is that not possible in your code?

> My question is, since mData is object array, rather than array, will it slow the grid loading?

As in the data source you are using is objects, not arrays? If so, then yes, in DataTables 1.9- there is a performance penalty for using objects. Not much, but it does become apparent in very large tables. DataTables 1.10 removes that issue and the performance is identical for both object and array data sources.

Allan

prathap

Hi Allan,

Thank you for your comments. Yes we are using global css style for all table headers. That is why we shifted to mData and is working. As you said, we will shift to 1.10 version as performance is key and we deal with large tables in most of the pages.

Appreciate your support.

Thanks,
Prathap.