SBX - Search With Button

SBX - Forum Post Title

DBMS: 515 Error message

Microsoft Dynamics GP Forum

Slaver asked a question on 15 Oct 2009 4:41 PM
My Badges

Question Status

Suggested Answer

Good day all:

 Here is my issue of the day...

I have a GP user that is getting an error message when they go to do a "receivables transaction inquiry" by customer in Dynamics 10.

Details:

Only occurs in this one company and only for this one user, tried a different user and no errors.

So when this user goes to run a "receivables transaction inquiry by customer" and inputs the customer number and then tabs out to see the results they get the following error:

[Microsoft][SQL Native Client][SQL Server]Cannot insert the value NULL into column 'ORTRXAMT',table 'tempdb.dbo.##1760642', column does not allow nulls. INSERT fails.

 =============================================================================

Then the following appears right after that error message:

The stored procedure rmTransactionInquiry returned the following results: DBMS 515, Microsoft Dynamics GP: 0.

===================================================================================

Here is the weird part..This only occurs for this one user login in this one company, and nobody else has any issues doing a customer inquiry...Plus this user has the same issue on any workstation they use....

If anyone has heard or seen this issue before it would be greatly appreciated to have some kind of answer as to why this is happening...

Thanks

Reply
Dencio responded on 16 Oct 2009 1:39 AM
My Badges

Hi,

Have you tried running the Grant.sql script again to DYNAMICS and company databases.  This will re-establish the recommended table permission for all GP (native and third party) tables to DYNGRP user role, which all GP users are inherently member of.

Otherwise, I would recommend you delete the user and recreate it.  As you pointed out, most of the weird user experience only occurs for this user.

The latter is the most straighforward approach when everything fails.

Cheers,

Dencio

Reply
Richard L. Whaley responded on 16 Oct 2009 6:06 AM
My Badges

A generally accepted tennent of diagnostics in SW is that only the first error message is valid.  Others can be generated when the first event fails.

I agree with the running of the Grant.SQL script and then deleting the user and re-creating it.

Reply
Slaver responded on 16 Oct 2009 8:53 AM
My Badges

Thanks for the reply...I have already tried removing the user and re-creating it again but i still get the same issue with that same user...I will though try the Grant.sql script to re-establish the permissions again...

 Thanks for the suggestion..

Reply
lainik responded on 22 Oct 2009 10:38 AM

Slaver

Thanks for the reply...I have already tried removing the user and re-creating it again but i still get the same issue with that same user...I will though try the Grant.sql script to re-establish the permissions again...

 Thanks for the suggestion..

Hi Slaver,

 I am having the same issue and all users seem to be effected. Did running that Grant.sql script fix your problem?

Thanks

Reply
Slaver responded on 2 Nov 2009 4:00 PM
My Badges

No the Grant.sql Script did not work..Although in your case because this seems to have effected every user, i would reccomend you running it.....There is a nice little "Automated Solution" through customer source for Dynamics 10 that does exactly what you want...

 In my case i am having to send this to our Microsoft Business Solutions IT dept to help me with my issue...

 

Reply
Ron McVciar responded on 17 Nov 2009 3:35 PM
My Badges

Any resolution to this? We have some simular errors.

Reply
Vinh Que Vu responded on 17 Nov 2009 3:48 PM

Create a DEXSQL.log and paste the last few dozen lines or so.  It may help out.

Also, you mentioned you recreated the user, but did recreate the user with the same ID?  If so have you tried creating the user with a new ID, such as attaching a "1" or something to the end of the name.  One last thing, you may want to check the schemas in SQL Server.  This is rare, but I have seen schemas affect specific user access when SQL decided to set them improperly.

Reply
Allen Schuette responded on 15 Jun 2010 7:15 AM

Thanks to Ryan Galang, I found the following identified and allowed me to fix this issue:

I did additional research and would like to provide an additional recommendation which is as follows:

a. Run the following scripts for both users (one user getting the error, the other user not getting the error) and compare their VIEWTYPE values:

SELECT * from MC40500 where SERIES = 3  and USERID = 'user1'
SELECT * from MC40500 where SERIES = 3  and USERID = 'user2'

-- SERIES = 3 (SALES)

b. 'VIEWTYPE' values:

 FUNCTIONAL = 3
 ORIGINATING = 4
 REPORTING = 5

c. Assuming that the client is not registered for MC, then there shouldn't be a user login referencing a 'VIEWTYPE'  = 4 or 5.

d. On a test company, you can run an update statement changing the 'VIEWTYPE' to 3 for the user login in question.

Reply
Leslie Vail responded on 15 Jun 2010 10:42 PM
My Badges

Boy Allen - you're a Rock Star.

Thanks to you and Ryan Galang. I hope this solved problems for the folks on this thread, but it certainly solved a problem that had befuddled me.

Thanks!

Kind regards,

Leslie

Reply
George Schimenti responded on 6 Jul 2011 12:20 PM
Suggested Answer

Actually, the above solution only disguises the real issue.  That just changes the defualt view in the customer inquiy to be functional currency view.  The real issue is that records exists in the RM20101 with no currency id.  These were records that came from GP 9 or prior.  the following update statement will correct this no matter what the currency view is.

UPDATE RM20101 set curncyid='Z-US$' where curncyid=' '

Reply
Michael Frayer responded on 21 Jul 2011 7:58 AM

I have followed this solution and it worked for me. I addition to the RM20101 table, don't forget to also update the RM10301 and RM30101 tables as the user may select to include Work, Open and History.

Reply
Noel Nqabeni Simela responded on 20 Aug 2013 3:12 AM
My Badges

Hi All,

I have a customer experiencing the very same issue.Did anyone find a solution for this.Slaver did you manage to resolve this?

Reply
Lisa Blair Ireland responded on 15 Jul 2015 8:45 AM
My Badges
Suggested Answer

We had a client run into this situation this week with GP 2010.  It was only happening with one user and we went through the normal cleanup, ended up with her logging in with a different user account.  Yesterday the problem re-appeared with the new user account but she was able to figure out what had happened:  She had pressed Ctrl-O (View Originating Currency) when she was trying to print (Ctrl-P).  (The company is not set up for multi-currency.)

Pressing Ctrl-R (View Reporting Currency) resolved the error!

Reply
Mark Cockburn responded on 19 Jan 2016 9:25 AM
Suggested Answer

Lisa Blair - your solution was spot on for me. We're running 2015R2. The user doesn't use keyboard short cuts, but I suspected she hit the keys inadvertently while doing something else. Sure enough...we brought up the inquiry, we clicked through the error message, hit the ctrl+R key and the results displayed as normal.

Thank you so very much!

Reply
TravisP responded on 22 Jun 2016 4:47 PM

Thanks Allen, that fixed it for me too.

Reply
George Schimenti responded on 6 Jul 2011 12:20 PM
Suggested Answer

Actually, the above solution only disguises the real issue.  That just changes the defualt view in the customer inquiy to be functional currency view.  The real issue is that records exists in the RM20101 with no currency id.  These were records that came from GP 9 or prior.  the following update statement will correct this no matter what the currency view is.

UPDATE RM20101 set curncyid='Z-US$' where curncyid=' '

Reply
Lisa Blair Ireland responded on 15 Jul 2015 8:45 AM
My Badges
Suggested Answer

We had a client run into this situation this week with GP 2010.  It was only happening with one user and we went through the normal cleanup, ended up with her logging in with a different user account.  Yesterday the problem re-appeared with the new user account but she was able to figure out what had happened:  She had pressed Ctrl-O (View Originating Currency) when she was trying to print (Ctrl-P).  (The company is not set up for multi-currency.)

Pressing Ctrl-R (View Reporting Currency) resolved the error!

Reply
Mark Cockburn responded on 19 Jan 2016 9:25 AM
Suggested Answer

Lisa Blair - your solution was spot on for me. We're running 2015R2. The user doesn't use keyboard short cuts, but I suspected she hit the keys inadvertently while doing something else. Sure enough...we brought up the inquiry, we clicked through the error message, hit the ctrl+R key and the results displayed as normal.

Thank you so very much!

Reply
ljgregory responded on 27 Nov 2018 10:05 AM
My Badges
Suggested Answer

I had this issue occur today and ran a SQL trace.   I found that there was a missing record in the MC020102 table.  I inserted the missing record and the error no longer occurs for either currency view, functional or originating.

Reply

SBX - Two Col Forum

SBX - Migrated JS