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
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
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.
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..
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?
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...
Any resolution to this? We have some simular errors.
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.
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.
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
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=' '
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.
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?
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!
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!
Thanks Allen, that fixed it for me too.
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.
Business Applications communities