"An error occurred while using the BCP utility-data was not correctly copied to the server. " I get this error while trying to log into out DEV version of GP. Nothing is different except I am now on Windows 7 64bit. i *can* log into our live system without any issue. I have made sure UAC is turned off and I am starting GP with the "Run as Administrator" option. I can get past the login screen, but once I choose a company, any company we have, I get the above error. If I go to my old system, Windows XP 32bit, I can get into the DEV system with no issue. This only seems to be an issue with my new 64bit OS. My ODBC is set up using the 32bit version of the ODBC program (found here: %windir%\syswow64\odbcad32.exe).
Any ideas? I am really stuck on this one and need to be able to test my new apps on the DEV environment before I put them live.
Have you opened GP Utilities (with Run As Administrator) from the Dev workstation?
I did and still same error as Stanley Need some help here please
Notice i've also checked the C:\Microsoft Dynamics\GP\SQL\Temp\TestBCP.bcp and inside says [Microsoft][SQL Server Native Client 10.0]BCP Connection is not enabled
(or something like that, its in spanish my software).
I have installed Microsoft SQL Server 2008 R2
Maybe something i need to setup for 32 bit?? or something?
I have my ODBC setup under 32 bit in C:\Windows\SysWOW64\odbcad32.exe
Hi Stan & Johand,
Have you looked at the KB870416 from Microsoft on Custome Source. It explains everything around the 64-bits environment setup with Windows 7 / SQL 2008.
Make also sure that you run the GP client with 'Administrator Rights' (look in the application properties, not only the local admin group).
Thanks for the reply, but i've been doing some search and i cant find where to look for the KB u saying... do you have a link?
Im kinda new to GP
NVM i found the Customer Source
See my server Database is installed under 32 bit
But where i cant find to work my GP is in a Workstation client, and the client installed for Native SQL is under 64 bits, so im installing now under 32 and see how it goes
Hello there Beat,
Thanks for your help and everyone else
Glad we could help solve the problems :-)
That's why the community exists...
Closing as resolved; Please let us know if you have any further related questions.
I have the issue where GP 2010 Utilities encounters issues because of UAC on Windows 7. We have a group policy set up for all members of the Great Plains active directory group, it gived these people modify access tot he GP folder. This eliminated the need for administrator for GP itself. But Utilties continues to prompt for administrator. Beat recommends reading KB870416. Same as Johand, I can not find this article.
Could anyone point me in the right direction.
Disabling UAC is not an option.
I've tried changing the compatability tab to run as administrator (I also tried to change shortcut properties - run as administrator). All this did for me was to immediately prompt me to enter the administrator password. The end users are not administrators so that's not what I'm looking for.
Any help would be greatly appreciated,
The KB870416 will not be of any help in your case... (and you have to get it only thru the customer source, because it's a confidential article).
I'm not aware of any solution to run GP (any version) in a Windows 7 / Vista environment without disabling the UAC and/or putting the end-user into the local administrator group (i've spent many hours of testing in this and couldn't find a viable solution).
The problem comes from the fact that the entire 'Program Files' folder under the new OS platform is system protected and accessible in read-only mode for a regular user. Even an authorized admin will sometimes get prompted by the system when doing some operation (like copy/move/paste files) in the PF folders, and this although the UAC is disabled and the user has local admin permissions...
Microsoft wanted to make the whole Windows platform more secure and less easy to fall apart by malware, and in some way they achieved that, but it went on the cost of easines of managing the applications. The most troubling is the fact that MS is the company that develops the Dynamics GP product and cannot get around the UAC and permission problem. Dynamics GP needs to be able to write into the PF folde where GP is installed...
Since the upgrade to Windows 7 in our company, I've massively reduced the amount of distributed GP clients and force most users to access it thru our Citrix application server... That not only cuts the maintenance to a minimum, but also avoids the hassle with the local security on the systems. Only a few users who uses a specific module that is not availabel to everyone gets a local copy of the GP client.
Hope this helps in your quest...
We do use Citrix for External users of GP but internally the cost would be prohibitive. Not something we'll pursue.
The Great Plains Active Directory group has been given Full Control Access to the "C:\Program Files (x86)\Microsoft Dynamics" through use of a group Policy, shouldn't that be enough? By doing this, Great Plains itself is no longer prompted at any point for administrator. Just Utilities. Also. It's only for GP2010. Giving the group Full control to the Microsoft Dynamics Folder fixes the issue for GP 10 AND GP Utilities 10. It's only GP 2010 that has the administrator prompt in Utilities.
I can ask then to provide access at the "C:\Program Files (x86)" level for testing purposes if you think this will help.
I have never tested the option thru GPO for the GP directory, but theoratically this should work for the GPUtilities.exe too, since it's located in the same subfolder.
Now you may want to check where your DynUtils.dic file is located... does it reside in a location that's accessible in R/W mode ? Generally speaking all the .DIC files need to be accessible in R/W to run Dynamics GP properly (and that is certainly true for the GP Utilities). The DYNUTILS.SET launch set is a smaller sub-set of the DYNAMICS.SET file, but the rules are essentially the same, except that all the .DIC files are starting with DU*. Check the location of all those files and their R/W accessibility.
Hope this helps.
I just double checked . . . All files (du*.dic, and dynutils.dic and dynamics.dic) are in the gp folder where the users have full control.
I think it's strange that this GPO works fine for GP10 on Windows 7 using UAC. Could it have anything to do with ODBC? We use the 32 bit version and for GP2010 we use SQL Server Native Client 10.0.
Otherwise could GP2010 Utilities update something that GP10 Utilities doesn't?
Thanks a lot for your time. . . .
Can you please provide an exact copy of the error message that you get ? Maybe it's worth trying to enable the DEX log tracing in the DEX.ini file :
replace all the FALSE by TRUE and save the file (you may need to open the notepad with Admin rights to be able to save the changes).
Start the DynUtils again and then look if you can find some .LOG files in the Data folder. Check also the presence of duinstall.log and it's content.
Don't forget to change the DEX.ini file back to FALSE after your attempt, otherwise the LOG files will keep growing forever.
I don't have a screen shot as I got called in to work on the problem after the test PC's were already updated. The Tech Staff is removing the GP client from a lab PC and putting it back on so I can try it.
Once she reinstalls GP I will turn on the logging in dex.ini and repost.
BTW. . . she did give Full control right from Program files on down at one point but it didn't help.
Again . . Thanks,
The question I have is why are the end-users, that aren't administrators, needing to launch into Dynamics GP 2010 Utilities?
The reason I ask is because unless they are updating databases or modified forms or reports, creating a new database or one of the other processes within Utilities, they shouldn't need to go into Utilities at all.
Besides the BCP error, which your only options are to disable UAC or use the 'Run As Administrator' permissions, you would need to login to Utilities as either DYNSA or SA, and my thinking is that if you're unable to give the end users the local administrator permissions on the machine that Dynamics GP is installed onto, you're definitely not going to give them the SA or DYNSA login password, which would give them almost all permissions within Dynamics GP and/or SQL Server.
Let me know if you have questions on the above information.