Share via

What is Column desSPRkmhBBCreh?

  • Article

David Meego

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:

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) Secure Link gives the following information:

Question:
What is the column name 'desSPRkmhBBCreh' that shows up in the DEXSQL.LOG file?

Answer:
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 or refer to the KB article below:

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

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.

David

Comments

  • Anonymous
    October 15, 2008
    Posting from Jivtesh Singh http://www.jivtesh.com/2008/10/makes-me-smile.html

  • Anonymous
    October 15, 2008
    Posting from Vaidy Mohan http://vmdyngp.blogspot.com/2008/10/vba-menus-for-vstd-dessprkmhbbcreh.html

  • Anonymous
    October 16, 2008
    Posting from the Dynamics GP Blogster http://dynamicsgpblogster.blogspot.com/2008/10/developing-for-dynamics-gp-weekly.html

  • Anonymous
    May 27, 2009
    Many people who have not been working with Microsoft Dynamics GP since the early non-SQL versions of

  • Anonymous
    January 06, 2011
    The comment has been removed

  • Anonymous
    January 09, 2011
    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. David

  • Anonymous
    November 16, 2012
    The comment has been removed

  • Anonymous
    November 16, 2012
    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.

  • Anonymous
    November 16, 2012
    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

    • Anonymous
      March 04, 2016
      The comment has been removed