What is Column desSPRkmhBBCreh?

David Meego - Click for blog homepageThis 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.

For example:

[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:

How to create a Dexsql.log file for Microsoft Dynamics GP (KB 850996)

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.

12 thoughts on “What is Column desSPRkmhBBCreh?

  1. I am getting this error in the dex sql log after after getting the following error on the home page:
    An error has occured in the script on this page.
    Line 335
    Char 6
    Error: The data is invalid.
    Code: 0
    URL: file:///C:/Documents%20and%20Settings/lclark/Local%20Settings/Temp/tmp3F1.tmp
    Do you want to continue running scripts on this page.
    I just started getting this error after the automatic updates for windows.   I have full control over the directory and I have the Office Web Components installed.  I even re-installed the Web Components.    I have a feeling it relates to a windows update, but I cannot find anything online.
    Any help would be useful!


  2. Hi Leslie
    The Column desSPRkmhBBCreh error occurs on all systems and can be ignored.  It is not related to your homepage issue.
    Can I suggest asking about your homepage issue on the newsgroups so others can help and also others can benefit from the answer.  There are links for newsgroups and forums on the right hand side of the blog page blogs.msdn.com/DevelopingForDynamicsGP.  The other option is to open a support incident.


  3. Unfortunately, this little bit of coding causes other problems down the line, although they are transparent to the end user. If your DBA has followed Microsoft's Best Practices when configuring their SQL Server, they will get an alert every time this code it executed. This is because the error when the invalid column is encountered causes SQL to close the connection. The program tries to re-establish the connection, but it cannot, which is a "unable to reuse a session with SPID xxx" error. A new session is created and the user never sees any problem. But the error in SQL Server is a severity 20 error and SQL Server fires off an alert. This is a perfect example of a sloppy programming practice that has consequences the developer can not foresee.


  4. Shaun5Stu,
    While your opinion matter as much as the next guys', I wouldn't agree with your assessment of "sloppy programming practice" for this design choice.
    As the article notes, this was a design choice that was taken because it performed faster than querying sysobjects to verify the table exists.
    You'll note too that this was coded on SQL Server 6 or 6.5 and the design choices taken on that version of SQL and its limitations wouldn't necessarily be how it would be written under SQL 2008, R2, or 2012 today.


  5. I would still argue this is sloppy programming. They were coding to a specific version of a particular database engine with no thought to the future. As programmers, they of all people should know programs change, hardware improves, and code often stay in production way longer than anyone expects. They were not thinking of the future. They intentionally created an error condition and made assumptions that the underlying database engine would always handle the error in a certain way and with a certain timing. They also gave no thought as to how that error would affect the database engine. That is bad programming, pure and simple. There is also no reason that this code should continue to be in the product. I've created a Connect item for this to be fixed: connect.microsoft.com/…/code-relating-to-fake-dessprkmhbbcreh-column-should-be-removed-from-product


    • Cute story aside, I completely agree that this is shoddy programming. The ‘desSPRkmhBBCreh’ column is the very definition of a hack. I wish I could say that I’m surprised that this hasn’t been remedied, but the quality of GP seems to be pretty low. It’s too bad that Microsoft has under invested in GP. I’m disappointed in myself that I selected GP for our company’s ERP system.


Please post feedback or comments

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.