Still no progress but I have updated the test code to show that the problem is most likely related to DA (or more likely something I’m doing wrong with DA)
using System;
using RemObjects.DataAbstract.Server;
using Elevate.ElevateDB.Data;
namespace ConsoleApplication1
{
class Program
{
static void Main()
{
// direct connection to database
var directConnection = new EDBConnection(@"Type=Local;ConfigPath=c:\devdata\vs2017\da-test\db;Database=mydb;UID=Administrator;PWD=EDBDefault;");
directConnection.Open();
Console.WriteLine("Direct connection opened");
directConnection.Close();
Console.WriteLine("Direct connection closed");
// DA connection to database
Configuration.Load();
var daConnection = new BaseConnection("--", @"ElevateDB.NET?Type=Local;ConfigPath=c:\devdata\vs2017\da-test\db;Database=mydb;UID=Administrator;PWD=EDBDefault;");
daConnection.Open();
Console.WriteLine("DA connection opended");
daConnection.Close();
Console.WriteLine("DA connection closed");
}
}
}
This is the output I get:
C:\devdata\vs2017\test\ConsoleApplication1\Bin\Debug>ConsoleApplication1.exe
Direct connection opened
Direct connection closed
Unhandled Exception: System.ArgumentException: Unable to find the requested .Net
Framework Data Provider. It may not be installed.
at System.Data.Common.DbProviderFactories.GetFactory(String providerInvariant
Name)
at RemObjects.DataAbstract.Server.DataProviderInfo.GetFactory()
at RemObjects.DataAbstract.Server.BaseConnection.Open()
at ConsoleApplication1.Program.Main() in C:\devdata\vs2017\test\ConsoleApplic
ation1\Program.cs:line 20
C:\devdata\vs2017\test\ConsoleApplication1\Bin\Debug>
In your second testcase two different approaches are used to load the database driver:
direct EDBConnection call relies on the assembly being referenced by the application
DataAbstract call uses ADO.NET provider that has be registered in the machine.config. The error you get means that there is no ElevateDB provider registration in the machine.config file for this particular .NET runtime version / bitness.
F.e. by default ElevateDB doesn’t register itself for x64 applications. Most probably this is what caused the issue you describe.
Possible solutions are to either register the DB provider in machine.config or to alter the Data Abstract configuration to directly use the ADO.NET driver assembly.
Latter approach is easier to maintain and it makes it easier to deploy the server application later.
Steps required:
Add reference to the Elevate.ElevateDB.Data assembly. Set reference Copy Local property to true
Add to the server project file C:\Program Files (x86)\RemObjects Software\Data Abstract for .NET\Source\RemObjects.DataAbstract.Server\DataAbstract.daConfig
Set BuildAction of the added file to EmbeddedResource
After this step the server application will use its own copy of the DataAbstract.daConfig file. This file contains descriptions of the database drivers used by Data Abstract.
Open the DataAbstract.daConfig file as XML using Visual Studio or any plain text editor.
Go to line 613, tag ElevateDB.NET. This section contains configuration of the ElevateDB ADO.NET driver
I had a copy of DataAbstract.daConfig left hanging around in my /bin/Debug/ folder from previous messing around. It appears that it will take preference over the one added to the project as an embedded resource. I removed it an all is well.
Yes, the .daConfig file copies have the following priority:
Local copy of .daConfig -> .daConfig embedded into the application -> Default .daConfig embedded into the RemObjects.DataAbstract.Server assembly
Local copy of the .daConfig file allows to adjust driver settings (f.e. to switch to a newer driver version) without recompiling the application itself.