This is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.
If you have ever spent time analysing a DEXSQL.LOG file you might have seen a reference to a table column called desSPRkmhBBCreh. This post explains what this column is used for and why it has the name it does.
SELECT desSPRkmhBBCreh FROM DYNAMICS.dbo.SY02100
[Microsoft][ODBC SQL Server Driver][SQL Server] Invalid column name ‘desSPRkmhBBCreh’.
The Knowledge Base (KB) article What is the column ‘desSPRkmhBBCreh’ ? (KB 875229) (no longer available) gives the following information:
What is the column name ‘desSPRkmhBBCreh’ that shows up in the DEXSQL.LOG file?
This is the way that Dexterity determines if a table exists. We select a bogus column ‘desSPRkmhBBCreh’ from the table in question. It will either return ‘Invalid column’ or ‘Invalid object’. If it is ‘Invalid object’, we know the table does not exist. This is faster than querying the system tables to find out whether a table exists.
What the KB article does not explain is what the letters of this “bogus” column name represent. They are infact the initials of five of the developers who worked on the changes needed for Dexterity to support Microsoft SQL Server. Below is a table with the initials and the names:
des Dan Seefeldt SPR Sean Ryan kmh Kevin Honeyman BBC Bruce Chenoweth reh Ray Holzhey
Below is an explanation from Sean:
If you want more info on where this came from, when we were working on the SQL product using an early version of ODBC, I found that it was taking quite a bit of time to invoke a meta data operation to determine if a table existed. We were doing this check a lot because Dexterity had the feature by default to auto create tables if they did not already exist. When I tried accessing a table that didn’t exist with a SQL query the result came back much faster with a “table not found” SQL code error. So I used this approach, picking a table column name that was unlikely to ever exist in a production environment. We were so under the gun trying to get the product out the door that I never had the time to go back and change this. I guess no one else has had time to change it either.
To activate SQL logging to create the DEXSQL.LOG file, you can either use the Support Debugging Tool (now GP Power Tools) or refer to the KB article below:
Note: Do not leave logging active in a live environment unless currently working on resolving an issue as it will have a performance overhead and eventually will create a file 2 GB in size.
Hope you enjoyed another little bit of history.
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.