There are a number of SmartList Builder Dex.ini switches and by default, none of them are created in the base Dynamics GP Dex.ini when you install SmartList Builder.

I thought it might be useful to have them all published in one place and will update this article as they are added – I doubt any would be removed but not impossible.

SMARTLIST_BUILDER_DEBUG=TRUE

This one is set to “FALSE” if it doesn’t exist in your dex.ini file.

The purpose of this one is primary for the developers of SmartList Builder to put extra debugging information into the application to find out errors in the logic of SLB.  Looking at the SLB code, it seems that the only time you would see this “debug dialog” would be if something failed with an error – typically a pass through Dexterity coding type of error that SmartList Builder uses – and this flag is enabled.  

I probably wouldn’t enable this one unless you are trying to debug something in SmartList Builder because it could just throw random messages even when nothing is wrong which might confuse users.

SMARTLIST_BUILDER_DEBUG_SQL=TRUE

This setting defaults to “FALSE” if it doesn’t exist in your dex.ini file.

Similar to SMARLIST_BUILDER_DEBUG but this one is for debugging the SQL that SmartList Builder generates to run the reports from SmartList Builder on SmartLists however this setting always runs and doesn’t check for “if this fails then show the SQL” – it always gives the statement generated and debugged.


This is useful to debug your Smartlists – however enabling the GP DexSQL.log is typically better for support and end user troubleshooting since it shows you the SQL and any error that happens from that SQL as SLB does not.

I would also not enable this one unless you are testing something on a private system.  Unlike the other debug setting which appears to only throw messages if there WERE an issue (that I found), this switch appears to always throw debug dialog messages even if there was not an issue.  Using a DexSQL.log is much more effective for debugging SLB/SQL issues than this switch.

SMARTLIST_BUILDER_HIDE_MODIFIED=FALSE

This setting defaults to “TRUE” if not configured in the dex.ini.

As you know, SmartList Builder has the ability to “modify” existing GP out of the box SmartLists.  From a technical standpoint, that isn’t exactly correct as that is not possible, however, what eOne has done is to recreate the existing GP SmartLists from scratch so that they look and work the same (hopefully!) as the original.

To avoid user confusion, by default SmartList Builder will then HIDE the original GP SmartList since the idea is that if you chose to modify the GP version then you don’t want to run the original version and are choosing the modified version instead with the added data.  If for some reason we wanted to see both – using this switch would then let SmartList show BOTH reports.



In the above screenshot, i now have two “Account Transactions” reports – one is the original version and the other is the “SmartList Builder Modified Version” and we can see that I did modify it to add a SQL Script which added the two User_Defined_Text01 & User_Defined_Text02 fields to the report as we can see.

SMARTLIST_BUILDER_KEY_DELIMITER=<value>

The default value for this is the pipe character – | – if not defined in the dex.ini.

When you create a new SmartList Builder report, you have to choose “Key Fields” for the report.  The purpose of the Key Fields is to identify row of data from the report so that when using a GoTo that you add to the report, SLB can find that data and then execute the goto properly.

Typically, you would choose multiple key fields – so if I were to be creating a SOP report – I would perhaps choose SOP Type & SOP Number.
When SmartList Builder runs the report the hidden “key data” gets created then using this value and would be created as 3|INV1000, 2;ORD1001, etc.

There isn’t a real reason to change this delimiter unless your data fields DID have the pipe field in it as data.  For example – if your SOP Number was INV|1000 instead.  If that happened the key value would get created as 3|INV|1000 and when using a Goto, we would parse it incorrectly and your goto wouldn’t work right.  You would have to change it in the Dex.ini to be another “not likely used in a key field character” like the graves ~ or backtick` or other unlikely character.

I can’t say that I’ve ever had to “fix a goto” by using this ini switch so likely you won’t have to either.

EXCEL_REPORT_BUILDER_VIEW_PREFIX=<value>

The default for this is “erb” if not defined in the dex.ini with this switch.

When you create a new Excel Report Builder Report, you enter in the Report ID and then the Report Name.  After tabbing from the Report Name field, Excel Report Builder defaults the SQL View Name field to be the prefix + your name with spaces and other characters removed.  You can, of course, name it as you like otherwise.  This setting changes that default “prefix” to whatever you like.

EXCEL_REPORT_BUILDER_REMOVE_DATE_FORMATS=FALSE

This value defaults to “TRUE” if not set in the dex.ini.

Not sure if this one matters anymore in SmartList Builder with the changes to SmartList on how it exports the data.  Testing this with the switched turned ON/OFF seemed to make no difference in my somewhat quick testing.

From what I can tell, “date” fields seem to get exported by SmartList as Functions to Excel such as this:

 

I believe that before Microsoft changed the export process, the fields were typically formatted as a short date such as 04/28/2023 which Excel wouldn’t automatically recognize as a “date” unlike sending it as an integer which Excel uses internally natively.

EXCEL_REPORT_BUILDER_EXCEL_PROVIDER=<value>

Without this dex.ini switch the default value is “SQLNCLI11.1”.  The previous default value was “SQLOLEDB.1” and was changed to SQLNCLI11.1 on the 18.03.0037 SLB release.  The reason for the change was that the previous provider didn’t support disabling TLS 1.0/1.1 and the new provider – SQL Native Client 11.1 does.

When you create an Excel Report Builder report and publish it, the Excel Data Connection created uses this as the provider in the connectionstring in Excel.  You could change the default back to SQLOLEDB.1 or whatever provider you like – this just affects the value in the connectionstring when the Excel file is creating during publishing.  After it is published to Excel, you can always change the connectionstring there to whatever value at any time as the functionality at that point is purely from Excel and not ERB at that point.