If you are in the habit of using slx_getNativeConnInfo() with the SalesLogix provider to retrieve a native connection string to the SQL or Oracle database in use by the SalesLogix provider, then get ready to have your apps break when you install SP1a for SalesLogix 6.1.
Background
The slx_getNativeConnInfo() procedure is a SalesLogix procedure implemented in the SalesLogix OLEDB provider. It will return a native connection string to the underlying database. Using this procedure you can create an ADO connection to the native database and do things that bypass the provider. You can create database views or procedures, complex queries using syntax not supported by the provider, bypass SalesLogix security for the current user, or to gain back needed speed when reading a lot of data.
SP1a for SalesLogix 6.1 makes a critical change to this procedure. The ‘sysdba’ password is now removed from the returned connection string – making it completely useless. There are some good things about this and some bad (IMO things weigh heaver on the bad side).
The Good (ehhh, not really)
The good part I suppose is that SalesLogix is more secure. However, IMO, this is a weak argument. I can see in companies where there is a very security conscious DBA that does not trust a SalesLogix developer to play in his sandbox that this might satisfy him. But really, in this case, they should just lock the security down for the sysdba user so access is locked down to the SalesLogix database only. So who cares if a SalesLogix developer can get the sysdba password programmatically anyway? Any security conscious DBA will have the sysdba user locked down to only the SalesLogix database.
The Bad
The bad gets really bad. The procedure is now completely useless. There is now no way to programmatically create views via a SalesLogix connection. This bites. Big time. I use views all the time. Often I would run something in the DBOpen even in SalesLogix that would get the native connection string via slx_getNativeConnInfo(), open an ADO connection and create any needed views. Then the views are ready and I can use them throughout the sales client. Now the only way this will work is if I also know the sysdba password for the local database (local meaning the LAN database for LAN client users, or the local MSDE database for remotes). If I know the sysdba password then I can simply append it to the connection string returned by slx_getNativeConnInfo() – but this means I have to hard code the password and if I am doing this in a SalesLogix VBScript then the hard-coded password can be viewed by anyone using a Script Debugger.
The Ugly
The worst part about this change is there was no advance notice it was even coming. I suppose it turned out good that SP1 was originally released and then pulled. This gave me a chance to see it on the change list for the service pack and then I had time to make the appropriate changes to my applications while the service pack was pulled. Now that it is officially released, I’ve been able to fix my applications that had broken because of this change. One thing to note: SalesLogix has promised that this type of breaking change will not be made in the future without prior notice to Business Partners and customers.
My Opinion?
My opinion is that the benefits gained by this security change are insignificant when considering the largest part of the SalesLogix population. The functionality capabilities lost by this change far outweigh the small benefits it adds. IMO they should have made this an option. In the SalesLogix Administrator they could have added an option to allow the sysdba password to be retrieved by the slx_getNativeConnInfo() procedure or not. There are many better ways they could go about this – all of them better than just removing it completely.
The more appropriate route for Best software would have been to provide a function called:
GetNativeConnection
That would return a native connection to the unerlying database. Then operations that were not supported by the SalesLogix OLEDB Provider could be still completed.