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) 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:
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)
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.
Posting from Jivtesh Singh
Posting from Vaidy Mohan
Posting from the Dynamics GP Blogster
Many people who have not been working with Microsoft Dynamics GP since the early non-SQL versions of
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.
Error: The data is invalid.
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!
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.
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.
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.
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
PLEASE READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.