DBMS: 515 Error message

(0) Share

Report

Posted on by Community Member

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

*This post is locked for comments

I have the same question (0)

All responses (23)

Answers (0)

Dencio 2,172 on at

Like (0)

Report

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

Was this reply helpful? Yes No
Richard Whaley 25,195 on at

Like (0)

Report

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.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

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..

Was this reply helpful? Yes No
ACCOUNTINGVA 20 on at

Like (0)

Report

[quote user="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..

[/quote]

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

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

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...

Was this reply helpful? Yes No
Ron McVciar 1,005 on at

Like (0)

Report

Any resolution to this? We have some simular errors.

Was this reply helpful? Yes No
vsquared 105 on at

Like (0)

Report

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.

Was this reply helpful? Yes No
Community Member on at

Like (1)

Report

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.

Was this reply helpful? Yes No
L Vail 65,271 on at

Like (0)

Report

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

Was this reply helpful? Yes No
Suggested answer

George Schimenti 22 on at

Like (1)

Report

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=' '

Was this reply helpful? Yes No