Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Form customization in Window_BeforeOpen(OpenVisible As Boolean)
set name=UserInfoGet.CreateADOConnection gives run time error 70 Permission Denied.
I don't believe this to be a permissions issue at the OS level since we have GP 2013 R2 clients on the same version OS that don't give this error.
It happens with UAC on or off and whether the client runs as administrator or not.
You probably have already checked but just to make sure have you checked the SQL permissions? Also you didn't mention if this was GP 2015 or not, but I'm guessing that it is. I'm also guessing that you are talking about the rich client and not the web client.
Hope some of this helps.
This is GP 2015, rich client, GP version is 14.00.0619 RTM.
I have verified the same thing happens whether the OS is Server 2008 R2 or Server 2012 R2.
I have run the "Grant" script on all company databases and dynamics.
Can you try running GP with "Run as Administrator". This available when you right click the GP in the menus. Hope it helps.
Did you have any luck in resolving this? I am having the same thing on a GP 2013 installation on my computer.
No. I haven't experienced it on a GP 2013 instance though.
So far it is limited to GP 2015.
I might suggest that you import your .package file running GP as administrator and logging in as sa.
If that doesn't work for you I'd be interested in knowing.
The error message just doesn't have much history on google or the gp forums I've seen.
You might want to follow this link as well
Discussion on exactly same issue.
I am having same issue in GP2015. At the beginning I thought it was something related to security of the DCOM but after playing a bit with this without luck, i am wondering if it a bug of GP2015.
GP is running in a Windows Server 2012. Using Administrator and sa.
Have you already fixed it?
Try using the fully qualified name VBADynamics.UserInfoGet.CreateADOConnection
and check the VBA project's references.
You need the 'Microsoft Dynamics GP VBA xx.00 Library' for your version of GP xx.00
fully qualified name did not work and reference is ok: Microsoft Dynamics GP VBA 14.00 Library
Have you filed an incident with support yet?
Is there a defect number to reference?
Cross-posting tammy's reply from partner support:
Thank you for the questions. This is a known issue with the DLLs installed as a part of the GP2015 Dexterity Shared Components. We are working to have this addressed in a tax release to be shipped later this month.
One thing to note is that once you install the GP2015 Dexterity Shared Components, you will get the error in both GP2013 and GP2015, if running/testing both on a single box. In order to get your GP2013 up and running again, uninstall the Dexterity Shared Components for BOTH GP2013 and GP2015; then reinstall the Dexterity Shared Components for GP2013 only.
Investigating the error, the problem is apparently caused by some service or assembly overall an update direct replacement of the local library.
When installing Dynamics GP 2015, possibly a reference to internally invokes the method: CreateADOConnection() was modified in the new version, altering the return value in Dynamics GP 2010 specifically affecting scripts built in VBA that include tethering and the generic exception that informs us (not necessarily could permissions).
Tinkering, actually I receive the error: "70 - Access Denied":
However, checking the properties of the class:
UserInfoGet linking CreateADOConnection() method provided by Dynamics differs from roles, credentials and even server path.
If we review the definitions in the object browser, all coming from the class:
From the library legacy:
VBADynamics and .DLL at the root: (Dexvba.tlb and Dexvba.dll)
Has not been updated or replaced by the new instance 2015. Even GP, it is possible to reference the new .DLL and is manifested in the error identically 2010 Gp.
Tim Foster gratifying that topical states have reported to Microsoft, and actually is a bug that is already gaining attention.
Workaround: (or temp solution... Bad, my English ...: /)
It is well known that security and maintainability, it is recommended to work with the tool set provided by the platform. However, in this scenario inevitably we must take off the gloves to the new KB creating our own VBA method that returns the connection with the credentials assigned directly.
• Leaving declared external variables
Dim Connection As New ADODB.Connection
Dim RecordSet As New ADODB.Recordset
Dim Command As New ADODB.Command
• We developed a function called by good practice, the style of C#:
Public Function ConnectionString() As ADODB.Connection
If Connection Is Nothing Then
Set Connection = New ADODB.Connection
.Provider = "SQLOLEDB" 'Case SQL Server, use provider Sql OleDB'
.Properties("Data Source").value = "SERVER"
.Properties("Initial Catalog").value = UserInfoGet.InterCompanyId
.Properties("User ID").value = UserInfoGet.UserId 'Global user o value: "sa" (not recommended)'
.Properties("Password").value = "Pass" 'Set Password'
Set ConnectionString = Connection
And a slight change have to do in the blocks we get the error.
Set Connection = UserInfoGet.CreateADOConnection()
Set Connection = ConnectionString()
'He continues his logic'
Command.ActiveConnection = Connection
'Close & Dipose'
Set Connection = Nothing
With this guarantee global function properly connect to our data source, not abstracting the factory Dynamics GP, so we must hand credentials.
Particular, allows us to connect to multiple sources and parameterized as VBA is concerned. The delicate, use values visible connection. However, we could compile a .DLL and reference it as VBADynamics.
Needless to add,
Jose, nice example of using native ADODB to re-implement the GP CreateADOConnection, but you forget one key point which is the password hash. using your method you'll need to hard code, in cleartext, a sql password which cant be the same as a GP user. Whereas the CreateADO will use the active user credentials without the need for explicitly setting a password.
we had the same problem and did Tammy's suggestion of un-instating then reinstalling shared components to fix Gp2013. We'll need to wait for the hot fix until we co-habitat the two versions.
Best Regards, friend NSANTIN.
Indeed!. In this case the method that retrieves the credentials must be explicit, as it as: CreateADOConnection Dynamics. Only the latter are picked up by logging run once through them.
That is why for safety and portability, compile function in another DLL that reference as VBADynamics and credentials are assigned by the login, invoking the logic as: CreateADOConnection2 for OpenConnection return.
Thanks for your feedback.
As we have noticed this is a known issue and it has been already fixed in the latest Hotfix:
Microsoft Dynamics GP2015 (14.00.0661)
In the “fix list”, this item was listed:
Business Applications communities