Error 430 in clsInitialize - Class Does Not Support Automation

SOLVED

Greetings,

         I have run into a strange issue I am hoping someone out there can assist with or might have some tips to further troubleshoot the issue.  We have made customizations to various existing tasks and created new tasks for Sage 500 2017.  

         The modifications have been installed to various machines and operating systems with no issues.   However, recently we have now run into an issue on Windows 10 machines where any of the customized tasks will not launch and the tracker is recording an error 430 "class does not support automation" in the task's class method InitializeObject when it makes the call to DefaultInitializeObject (CAppInterface.dll).

         Standard Sage 500 tasks continue to work so it appears to be some sort of permissions issue.  Going along that line line of thinking and using one of the tasks developed with the SDK, a test system was set up and the following done:

  • Logged in as Admin
  • Turned off all virus checkers and Windows Defender
  • Installed Sage 500 client using proper compatibility and administrative privileges.
  • Copied the SDK developed tasks to the appropriate folder
  • Using a command prompt with administrative privileges manually registered the ActiveX EXE using regserver command
  • Restarted Sage 500 with Administrative privileges

         After doing all this, I was still receiving the error 430 when trying to start the task from the desktop.  A review of the CLIDs for CAppInterface shows the correct GUID expected by the task.  I also verified that registry entries were made for the SDK task I was testing with.

        Another thing we tried was to ensure the task was compiled on a 64 bit machine and that the references were pointing to the proper Sage folder.  Still no Joy.

        I even went so far as to spin up a Windows 10 VPC in Azure and test there to see if I could duplicate the issue, but I was unable to.  At this point, I am scratching my head trying to think of what the issues might be with these Windows 10 machines when it comes to allowing access to CAppInterface when starting a task.

        Any ideas or tips would be greatly appreciated.

Thanks

Parents
  • 0

    I guess it might depend a bit on the version, although I don't think that code has been modified for a while. At instantiation I would think an unhandled exception might be likely in gbIsModuleActive if you created a new module. That's the code that fires a query like: "SELECT Count(*) Fld FROM tsmCompanyModule WHERE CompanyID = &" 

  • 0 in reply to Contefication

    No new module.  I am just testing a simple SDK program.  Also, modifications were made to Enter AR Invoice as well.  Before installing the modified version, Enter AR Invoices worked.  Once the customization was installed, same Error 430 in initialization call, which is a method no one ever touches so it should simply work.

    As I stated, I set up a Windows 10 with the same version of Sage 500 2017 locally and cannot replicate the error, which leads me to believe it is some sort of permission or security setting causing the problem.

  • 0 in reply to LouDavis

    It might seem backward but have you traced the task to see how far it gets in the back-end? You're apparently not getting to Form Load, so it's tough to debug. Also, have you checked if there is a difference in the Windows 10 version in your tests? 

    There isn't a lot of complexity to initialization and Tracker might not be reporting accurately. Since you can't debug  you can trace it in SQL to determine if you get the correct query activity. The initialization just plugs into the framework, establishes a form connection through DAS, then verifies task permissions and that the module is activated in the company. If a connection isn't established and the error isn't trapped then a 430 might be the result. 

    DefaultInitializeObject(oClass As Object, oFramework As Object, ByVal lContext As Long)

    Initializes the  MAS 500 Interface Class object represented by oClass argument. Sets its standard set of  public variables which includes moFramework, moSysSession,moDasSession, moAppDB.

    Also, it might seem really primitive these days, but what about a system inspector comparison? It's a 25 year old tool but might have some clues as to a difference in environments.

  • +1 in reply to Contefication
    verified answer

    Found the issue.  When Sage 500 2017 was initially released, the client installer was bad so Sage had to re-release it to correct issues that would occur.  This particular company had somehow obtained and installed that bad client installer.  Since this was a test system, we provided the latest client installer that could be downloaded from Sage.  

    Once the old client was uninstalled, the machine cleaned up, and the current installer was run, the modifications built with the SDK worked as they should.   

    First clue should've been the company was using the base version of 2017 with no updates.  I don't think you can apply updates to that bad client, but I could be wrong.

Reply
  • +1 in reply to Contefication
    verified answer

    Found the issue.  When Sage 500 2017 was initially released, the client installer was bad so Sage had to re-release it to correct issues that would occur.  This particular company had somehow obtained and installed that bad client installer.  Since this was a test system, we provided the latest client installer that could be downloaded from Sage.  

    Once the old client was uninstalled, the machine cleaned up, and the current installer was run, the modifications built with the SDK worked as they should.   

    First clue should've been the company was using the base version of 2017 with no updates.  I don't think you can apply updates to that bad client, but I could be wrong.

Children
No Data