Hi all, I have written a Windows Service in C# that connects through the ABC COM component to retrieve customer data from Axapta. The service runs and works properly on my development machine, but I can’t get it to work in my test environment, or on another developer’s machine. I keep getting the an error (listed at the bottom of this post). I have set up a simple test application that just connects to the ABC and calls WinAPI.getTickCount to test the connection, again it works on my machine, but fails on other machines with the same error (so the problem is definitely not that I am using a service). On both these machines, running Axapta normally using the configuration specified by the test application works fine, it is just connecting through the ABC that fails. The error indicates a file permissions issue, but as I said the same user is able to connect to Axapta normally (and I have made sure that the ABC is running under interactive user), and can access all necessary files. It was suggested on the AxaptaDev yahoo group that I try copying the CURRENT_USER Axapte registry settings into the LOCAL_MACHINE tree, but that did not help. Does anyone have any suggestions on how to fix this, or on how to debug it more effectively? At this point I cant get into the guts of the ABC so I can’t figure out exactly what is causing the failure. Thank in advance, Matt “at AxaptaCOMConnector.Axapta2Class.Logon2(Object user, Object userPassword, Object Company, Object language, Object serverManager, Object objectServer, Object configuration, Object isWebUser, Object reserved1, Object reserved2) at AxaptaCommsTest.Form1.connect() File Error : The application files are not accessible. This can be caused by another Navision Axapta instance using the application files in exclusive mode. Navision Axapta cannot be executed. Please restart the Navision Axapta Business Connector before logging on.”
Hi, How many simultaneus ABCs there is in your license? br,
Hi there, We have three ABC licences, and we’re not using any of them (this will be the first app to use them). We also don’t use the web portal, so that’s definitely not using one. I will try shutting down my machine and testing on another machine to make sure they are not competing for licences, but I doubt that’s the problem… Thanks, Matt
Hi, Have you checked not to have a 2-tier client using the application in exclusive mode while you work with the COM? (In SP1 and SP2 AxConfig utility has a checkbox Open the application files in excusive mode.) Regards, Ciprian
It would seem I was wrong, the file permissions were the problem after all. Apparently the ABC requires full access to the .aoi files (where the client seems to be happy with just read, list and execute. I used filemon to track what files were failing, and when the ABC tried to connect, it failed while accessing the index file. Thanks anyway for the suggestions
Oh, and sorry for the double-post, but I thought some of you may find the connection tool I used useful. Here is the full source (sorry for the lack of comments, it is intended as a quick testing tool, nothing more). It requires the configuration you choose to have a user and password for the COM specified in the config tool. Regards, Matt //Form1.cs using System; using System.Drawing; using System.Collections; using System.ComponentModel; using System.Windows.Forms; using System.Data; using Microsoft.Win32; using AxaptaCOMConnector; namespace AxaptaCommsTest { ///
Hi all. I though I would mention what the end result of this was. After much permission fiddling and checking, we determined that the Axapta configuration tool seems to impose a local user account on the ABC when you stop/start it using the ‘Business Connector’ tab. This means that if you set a use for the ABC to run under in the component services MMC snap-in (in the identities tab on the properties pane), and then stop the service and restart it using the configuration tool, the service is forced to log on as the currently logged on user instead. Moral of the story? The easiest way to prevent hiccups is to ensure the local user has write access to everything needed by the ABC (yes, this sucks).