RangerMSP Business Automation for successful ITs


Go Back   RangerMSP Forums > RangerMSP Software Discussion Forum (CCRM)

Thread Tools Search this Thread
 
August 9th, 2018, 08:37 AM
CraigYellick
 
Posts: 53
I am attempting to call the Commit API from an Access VBA code module.

Calling CmtInitDbQryDll returns an undocumented error code of 1024.

Calling CmtGetDescriptionByStatus for that error returns either a blank or "Eror ADV File". (Yes, Eror not Error.)

Background info:

App name is CSPBilling. DB path is known to work in other custom .Net apps that are also running successfully on this workstation.

Regarding the API DLL files: this was a major hassle, I tried locating the files that are referenced as "C:\DemoVBA\ThirdParty\UserDev" in all the code samples to numerous places on my workstation. The only way I could even make the initial CmtInitDbQryDll call was to copy the API DLL files to the "CurDir()" folder which on my workstation is "C:\Users\cyellick\Documents". This doesn't seem right but at least I could make the call.

VBA is version 7.1 running in Access 2016 on Windows 10 Pro 64-bit.

-- Craig
 
August 9th, 2018, 11:35 AM
Support Team
 
Posts: 7,520
Thank you for posting. It seems like database access dll files are missing.
Please copy the following dll files and see whether it helps:
\LastVer\ace32.dll
\LastVer\adsloc32.dll
\LastVer\adslocal.cfg
\LastVer\Ansi.chr
\LastVer\axcws32.dll

On a side note: The UserDev folder it the one to develop in, when you do you normally do not need to copy any file manually.

Hope this helps!
 
August 9th, 2018, 02:30 PM
CraigYellick
 
Posts: 53
Thanks. I had most of those files copied but didn't realize Ansi.chr was important.

I don't get an error any longer on the CmtInitDbQryDll call but when I exit the Sub that contains the call, Access throws "Runtime error 49: Bad DLL calling convention".

I don't think I'll be able to use the UserDev folder because it looks like Access will not load .DLL from just any path.

Here's the relevant code that's throwing the error:

Private Declare Sub CmtInitDbQryDll Lib "CmtDbQry.dll" ( _
ByVal xSoftWareName As String, _
ByVal xDbPath As String, _
ByRef xvStatus As Integer)

Private Declare Sub CmtGetDescriptionByStatus Lib "CmtDbQry.dll" ( _
ByVal xCode As Long, _
ByVal xDescLen As Long, _
ByVal xvDesc As String)

Public Sub TestConnection()
Dim nStatus As Integer
Call CmtInitDbQryDll(C_AppName, "\\edc-commitcrm\CommitCRM\Db", nStatus)
If nStatus <> C_Ok Then
Call CmtGetDescriptionByStatus(nStatus, C_ErrorDescSize, aErrorDescSize)
MsgBox ("Commit Init failed. Status Error code: " & nStatus & Chr(13) & Chr(10) & aErrorDescSize)
End If
End Sub

-- Craig
 
August 10th, 2018, 07:03 AM
Support Team
 
Posts: 7,520
Thank you for your reply.

It seems like the way you try to access the API dlls is wrong, at least based on the error you receive "Runtime error 49: Bad DLL calling convention", that I don't think it is a RangerMSP API message, and if that's the case maybe you can further research it online. The API dll is a standard Windows dll.

Having said that, I wonder whether it would be better to use the higher level API libraries where you already have all dlls wrapped and can be accessed using native C#, VB.NET or C++ objects. Click to learn more about high-level API libraries.

Hope this helps.
 
August 10th, 2018, 08:07 AM
CraigYellick
 
Posts: 53
I added the call to the api termination and that didn't help. Since there are no errors during the api calls themselves it looks like the memory clean-up is failing with the procedure ends.

I'm using Access because that's the one place where all the data exists for doing the integration work that I need. Cheap and easy -- all the other .Net options would take a lot longer to develop.

-- Craig
 
August 10th, 2018, 10:25 AM
CraigYellick
 
Posts: 53
Hey, great news! The Commit CRM API works fine in Access VBA.

When I put a full sequence of commands in a single procedure they all run without any difficulty. As soon as the procedure ends it throws the DLL-related error but thankfully VBA can catch it and ignore it.

There may well be some kind of lingering after effects that could cause more trouble eventually so I would not want to trust this to run all day everyday. The user context of this app is one person using it once or twice per month for a couple of hours so I'll take the risk.

-- Craig
 
August 10th, 2018, 10:56 AM
Support Team
 
Posts: 7,520
Great! Thank you for the update.
Reply





All times are GMT -6. The time now is 05:54 PM.

Archive - Top    

RangerMSP - A PSA software designed for MSPs and IT Services Providers
Forum Software Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.