We have some custom functionality that ties directly to a user's Tessitura login/security profile by calling FS_USER and then matching it against the db_userid column in T_METUSER. However, since Windows Authentication rolled out, we've realized that in T_METUSER the db_userid column has switched over to a value of NULL for anyone using authentication to log in, instead of the familiar 8-character login.
At a glance, it looks like we could work around the problem by simply matching FS_USER against the userid column instead of db_userid - for anyone not using authentication, the two columns appear to be identical. However, before we plow forward, I was hoping to consult the braintrust to see if there are implications or reasons why this might be a terrible idea! Thanks as always.
Hi Evan - John is right about FS_USER() for pre-v15.1 versions. In v15.1, there is a new scalar function called FS_USERNAME() that should be used. Here is the statement from the v15.1 release notes:
"A new scalar function, FS_USERNAME(), has been added as a replacement to FS_USER() everywhere, including custom tables, views, and procedures. This allows the update of the function to strip the domain name for windows logins before returning the first 8 characters of the user name for audit columns. FS_USER() is officially deprecated and it should no longer be used."
Thanks for that David! We are actually talking about moving to 15.1 soon, so nice to put that on my radar before we start!