If the Data Browser is also failing to launch then I suspect the problem has to do with the vertical CenterPoint thinks is installed.

If you open the registry and navigate to: \\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Red Wing Software\CenterPoint

There should be a "Vertical" value, this tells the External API (and Data Browser Tool) which vertical of CenterPoint to configure for.

If this is an Ag/Payroll install, perhaps the vertical is in as "Payroll" and should be "Ag"; if this is the case it's usually a result of the products being installed in the incorrect order - in this case, the Agricultural product should have been installed first, then Payroll.

Regards,

- Aaron.

Are you able to open the same database that the External API is attempting to open within CenterPoint manually without an issue on those same PCs?

Just to be sure I understand:

The problem is in the Data Browser?
You have both Ag and Business installed?

It does sound like it's getting the wrong vertical. Normally, applications get this from the registry, but it can be overwritten in the app's config file.

Take the command line version of the Data Browser, the .exe file name is CenterPointDataBrowserConsole.exe. The config file name (in the same folder) is: CenterPointDataBrowserConsole.exe.config

If the config file has a VerticalName section like this, then you should delete the whole line where the VerticalName is set.

<appSettings>
<add key="ApplicationName" value="CenterPoint" />
<add key="VerticalName" value="Business" />
</appSettings>

That said, it doesn't seem likely that installing a new version would have this line, but it's worth a check.

With the test machines, when you open the Data Browser, does it open a dialog in which you have to specify a user name and password? Of course, you'd have to supply the same user name and password in your application's OpenDatabase because it's not going to be able to pop up an Open Database dialog to ask you for that information.

Your code that calls DataAccessAPI's OpenDatabase method fails, right? I don't suppose that application has a .config file with the vertical set?

I've been talking to Aaron about this and the only thing we can think of trying is to run your code snippet on a test machine here. We'd need your <yourapp>.exe.config and the code snippet that opens the database.

I've also searched to see what changes we've made to the Data Browser. Looks like the only changes since June 2, 2017 we when I put a version number into the Data Browser's main form's text. And, of course, in January, 2019 when we updated to .NET 4.7.2 (which didn't involve any code changes).

I made a simple program that allows you to select the database, type in user name and password and connect to the database. Found out something interesting. Of course it always works on my machine. But if I put it on one of the test machines first time you click connect, I get A connection to the database cannot be established. But then if you click connect again it will connect. Third time it won't, 4th it will.

I'll send you the code, but I can't seem to figure out how to upload it through the forum.

I installed CenterPoint Accounting (Business) 14.3.2 on a test machine and was able to run your tool without any issues.

I've uploaded a special build of the RedWingSoftware.MainCBL.L0.V1.DLL file to the same location I had you upload your files.
This includes some additional error trapping that may help us pinpoint the problem.

• Rename your copy of this file in the "ReflectedDLLs" folder
  
  
• Copy this test version of the file into the same folder (do not delete or overwrite your original file.)
  
  
• Try your tests again to replicate the error - you should get additional information about the underlying issue.
  
  
• Remove the test version of the DLL and replace it with your original copy (this file is not production ready and will interfere with any future updates.)
  
  
• Let us know what the additional text of the error is.

Regards,

- Aaron.

Based on this new information, I feel like there may be some out-dated DLLs in <Program Files>\Red Wing Software\CenterPoint\ folders.

My recommendation would be to rename "<Program Files>\Red Wing Software\CenterPoint" and then do a repair of the CenterPoint installation(s) on the PC.
This will insure that only the expected DLLs are installed.
Then drop your app into the ReflectedDLLs folder and try it again.

We have had one or two customers run into this with the 14.x release; we removed components in this version and updated other 3rd party components but for some unknown reason in these instances the files never got updated or removed with the new installation.


- Aaron.

OK, so in that scenario the likely problem is that the version of CenterPoint Payroll installed is not the same version as Ag/Business which makes them incompatible.
If you have updated the vertical to 14.3, then you will also need to upgrade Payroll to 14.3.

- Aaron.

Interesting, I can replicate this now if I too install Payroll on a test machine.
OK, we will dig into this and keep you updated.

- Aaron.

We're still working on the why, but I believe we have a short-term solution for you.

It seems the inclusion of the Payroll components is causing the API to look for a referenced DLL that is not in the ReflectedDLLs folder.
So, if you move your application to the "CenterPoint" folder instead of the "CenterPoint\ReflectedDLLs" folder and then modify your executable ".config" file to include the following in the <runtime> section:



That should resolve your problem - at least it did on my test machine where I'd replicated your situation.

- Aaron.