|
|||
|
|||
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 |
|
|||
|
|||
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! |
|
|||
|
|||
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 |
|
|||
|
|||
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. |
|
|||
|
|||
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 |
|
|||
|
|||
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 |