SY01401 User Defaults - errors

[barbola]

When we upgraded to GP 9.0 first time logging in asks to change password. It allows you to change it to the same one it was before. I changed mine to a different one (PW2).

I was using my login on my workstation and another one just fine. Then I changed my password back to PW1. Now the other workstation won't let me log in. So I logged in as 'sa' and reset it to PW1. Then MY workstation would not let me in, so I had to reset it there to PW1. Now the other workstation won't let me in???! Do I change it back to PW2 in both places?

Anyway I am also getting an error trying to log into a company where I am stuck. It is supposed to pop up the screen to view current logins so I can delete myself. It does, but first I get the following error:

"A get/change operation on table 'coUserDefaults' cannot find the table."

I click More Info and get this message:

"[Microsoft][ODBC SQL Server Driver][SQL Server]Invalid Object Name 'SY01401'"

I looked at SY01401 and my username is in there 3 times as follows:

UserID coDefaultType USRDFSTR Dex_Row_ID
ME 1 5 16
ME 13 1 44
ME 13 1 43

I can't find a thing on CustomerSource about this and hoping to avoid the VAR charges for now if you can help?

thanks
ME

 

[Wolf6]

Hi barbola.
Just a quick thought. Did you run the grant.sql statement against the company and dynamics DBs after your upgrade?

Scott

 

[GPUser05]

Hi Scott,

I am having the same problem but not on different workstations. If I try to log in through SQL Query Analyzer, it will not connect with same password that I log in through Dynamics. I used the same password for both before upgrading to GP 9.0. Could you please let me know how to run this grant.sql statement?

Thanks for your time.

 

[barbola]

I didn't run grant.sql because I didn't see it in the instructions. I thought of running it but looked for some documentation as to why it should be run and couldn't find anything. I guess it wouldn't hurt though - that may help get rid of the 'deleting user' problem.

I did find a KB article about the new changes with GP 9 such as userid's being case sensitive. The article also said to check the DSN settings on both workstations, but we did and they are the same. This is what it said, and this is exactly our problem, but the resolution doesn't help:
[italic][blue text]
SYMPTOMS
When you try to log on to Microsoft Dynamics GP 9.0, you may receive the following error message:
This login failed. Attempt to log in again or contact your system administrator

CAUSE
This problem may occur if the password is changed at another computer. If the password is changed at another computer, the user cannot log on to Microsoft Dynamics GP 9.0 at the user's computer because the server name in the Data Source (ODBC) is set up differently than the computer where the password is encrypted.

Resolution
To resolve this problem, verify the Data Source (ODBC) that you use for Microsoft Dynamics GP at the computer that is receiving the error message. Verify the Data Source (ODBC) as follows:• Click Start, click Administrative Tools, click Data Sources (ODBC), and then double-click the DSN connection.
The DSN should list one of the following things:• The name of the computer that is running Microsoft SQL Server
• The TCP/IP address of the Microsoft SQL Server that is entered in the Servername box
If you are not sure of the name of the computer that is running SQL Server or the TCP/IP address of the computer that is running SQL Server, you can verify the Data Source (ODBC) on a working computer. For more information about an ODBC set up, click the following article number to view the article in the Microsoft Knowledge Base:
870416 ODBC setup on SQL Server 2005, SQL Server 2000, SQL Server 7.0, and SQL Server Desktop Engine 2000 (MSDE)
[/blue text][/italic]

I'll run the grant.sql and see if this helps both or one.

thanks.

 

[barbola]

[blue]duh I need to learn how to read directions (re: tgml)[/blue]

 

[barbola]

grant.sql did diddly squat.

 

[winthropdc]

V9.0 forcing you to reset passwords from a previous version is expected. The encryption used by v9.0 is stronger than used in the previous versions so getting you to change password allows the new encryption to be applied at the SQL Server.

Even if you go back to the same password you had before at the Dynamics GP application, it will actually be different once encrypted at the SQL Server.

The Company Defaults table is expected to have multiple records per user. It stores a number of different settings on a per user per company basis.

Please make sure that the ODBC settings have all the translation/conversion/ANSI settings etc unchecked.

David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer
Microsoft Dynamics Support - Asia Pacific

Microsoft Business Solutions

http://www.microsoft.com/BusinessSolutions

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[barbola]

I will check again, but I did check the ODBC setups on both workstations and I still get the errors.

Maybe I will need to recreate the DSN on both machines.

 

[jazgeek]

careful on the re-dsn. I ran into a problem when we moved sql servers from one machine to another. I deleted the dsn and then re-created it using the same name. Must have been something stuck in registry because on 2 machines I was unable to set the same dsn up (kind of important if you're running crystal reports)

what I ended up having to do was to delete the user's profile on the local machine and re-create it.

kind of a pain in the butt as it loses all settings such as desktop/favorites etc. but it did clear the dsn cache out and allowed me to re-enter the same dsn name.



-----------
and they wonder why they call it Great Pains!

jaz

 

[jymm]

Hey barb - I had similar issues when we installed -

GP 9 works MUCH more closely with SQL security and more specifically how SQL interfaces with AD (plus UPPPER/lower case now makes a difference) --- I know that for our GP users I went into Management Studio - expanded security - expanded logins - right click on a user and selected properties. Then I unchecked the 'Enforce Password Policy' --- at least the users did not need to put in new passwords or take the default rules from a policy that may not be applicable...

 

[barbola]

What is management studio? Is that in SQL 2000?

Jaz, I won't delete the DSN, maybe create a new one but I really don't think this is our problem. We don't use Crystal (I'm partial to Access).

We had this problem for other users. If I reset their password for them they couldn't log in on their own wkstn until I reset it on their wkstn. Their original problem was likely due to wrong case of username.

I'll check those dsn's right now.

 

[barbola]

OK. I had noticed the other computer had a File DSN whereas I had a System DSN. I set up a File DSN on my workstation, but it didn't change anything.

So, I set up a System DSN on the other workstation and made sure both had the EXACT same settings and VIOLA!

It worked!

thanks all!

 

[jazgeek]

great plains should be a system dsn

-----------
and they wonder why they call it Great Pains!

jaz

 

[barbola]

That is strange because the one that didn't have a system DSN is a Citrix server...or maybe it's different that way. I hope I didn't mess up our terminal server users. Come to think of it, one user couldn't get in but I think it was maxed out. eek. I hope that's the case. Cuz I was able to get in, so probly that's the case. Oh great, now that I'm home...I won't sleep.

 

[jymm]

have you ever thought about creating a file with the registy entries for your DSN - makes it MUCH easier to create them on all of the other boxes...

If you have never done it before
Start -> Run -> RegEdit -> surf to hkey_local_machine -> Software -> ODBC -> ODBC.INI

From there find the DSN that you want to copy & right click on it. One of the choices is 'Export'. This will create a file that you then just double click on for each other machine. Saves ooooodles of time for those 'creative' users who some how still have admin rights (insert slightly evil smile here).

 

[RobertC22]

Hello All!

GP9 uses the SERVERNAME contained in the DSN to as a key to encrypt your password before passing through to SQL (regardless of wheterh version 2000 or 2005).

Therefore each machine that will access Great Plains - be it workstation or Terminal Server - should use the same TYPE of DSN (System, User or File) with the SAME servername (do not mix IP address and servernames).

If you do mix, you will get the issues experienced above!

------
Robert

 

[barbola]

thanks jymm. Yes I have admin rights, scary eh?. we're not a big office.

 

[barbola]

I don't think I posted to say that I re-entered the DSN's and it now works.

BUT, in my original post I also mentioned a problem with trying to delete my stuck userid. That part wasn't resolved but I believe it is a known issue?