Hi all, I'm using Export CDT To Excel smart service. Let

@mihaioctaviant Just to confirm from a custom ordering and data types perspective, we have 22 fields in the CDT out of which many of them are Text and few are Number Integer. And as of now we are using 17 fields as of now in the 'Cdt_fields_to_export' attribute and that too in a entirely different order from the order, the CDT maintains. We have been using the smart service for more than one and a half year and neither there is a single issue till date in the data being exported (the plugin is also tested to work on huge datasets) nor with the configurations. Further I also remember that the plugin worked well when there are fields of type Boolean in the CDT. And I have to say that all the fields in the CDT are single and there aren't any nested CDTs, that is, the CDT is flat.

What I have noticed in my implementation is, if there are any fields of type multiple or nested CDTs in the main CDT, the plugin doesn't work in a desired manner. So I have gone for creation of a formatted CDT which is flat (no nested CDTs) and only contains fields of single type.

It might be worth focusing on the other configurations in the smart service and the structure of the CDT as well.

It might seem like a weird thought - but is there a chance of any influence on the working of smart service because of the number in the name of CDT fields?

Hope the above information will be of some use to you and we have extensively implemented the same smart service in one of our projects and I would be happy to contribute just in case if you come back with questions.

As said by other practitioner, it hasn't got to do anything with the template (such as n column based) and your understanding re the same is correct.

@mihaioctaviant Just to confirm from a custom ordering and data types perspective, we have 22 fields in the CDT out of which many of them are Text and few are Number Integer. And as of now we are using 17 fields as of now in the 'Cdt_fields_to_export' attribute and that too in a entirely different order from the order, the CDT maintains. We have been using the smart service for more than one and a half year and neither there is a single issue till date in the data being exported (the plugin is also tested to work on huge datasets) nor with the configurations. Further I also remember that the plugin worked well when there are fields of type Boolean in the CDT. And I have to say that all the fields in the CDT are single and there aren't any nested CDTs, that is, the CDT is flat.

What I have noticed in my implementation is, if there are any fields of type multiple or nested CDTs in the main CDT, the plugin doesn't work in a desired manner. So I have gone for creation of a formatted CDT which is flat (no nested CDTs) and only contains fields of single type.

It might be worth focusing on the other configurations in the smart service and the structure of the CDT as well.

It might seem like a weird thought - but is there a chance of any influence on the working of smart service because of the number in the name of CDT fields?

Hope the above information will be of some use to you and we have extensively implemented the same smart service in one of our projects and I would be happy to contribute just in case if you come back with questions.

As said by other practitioner, it hasn't got to do anything with the template (such as n column based) and your understanding re the same is correct.