Does DA check for the MDAC version at all?


(antonk) #22

Hmm, this is where the hard part begins. Please post here your .daConfig file.

Also I would like to take a look at the actual exception trace of this error. There is two ways to get it: either via attaching debugger to the Schema Modeler process or (atm this would be faster and easier) by using this small project: ConnectionTester.zip (3.8 KB)

Add your .daConfig as resource (so Data Abstract will see the new driver definition) and set the connection string value in this line:

 var connectionString = @"SQLite.NET?Server=localhost;Database=C:\Users\Public\Documents\RemObjects Samples\Database\PCTrade.sqlite.db;";

Then run the app and it will show what exactly did fail. Please post this info here too.


(Alan Olson) #23
System.ArgumentNullException: Value cannot be null.
Parameter name: type
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at System.Activator.CreateInstance(Type type)
   at RemObjects.DataAbstract.Server.InternalProviderFactory.CreateConnection() in c:\CI\b\rofx\917\Data Abstract for .NET\Source\RemObjects.DataAbstract.Server\Configuration.pas:line 842
   at RemObjects.DataAbstract.Server.BaseConnection.CreateConnection() in c:\CI\b\rofx\917\Data Abstract for .NET\Source\RemObjects.DataAbstract.Server\ConnectionManager\BaseConnection.pas:line 191
   at RemObjects.DataAbstract.Server.BaseConnection.Open() in c:\CI\b\rofx\917\Data Abstract for .NET\Source\RemObjects.DataAbstract.Server\ConnectionManager\BaseConnection.pas:line 350
   at ConnectionTester.Program.Main(String[] args) in D:\dev\ROTest\ConnectionTester\Program.cs:line 18

(Alan Olson) #24

here is my daConfig file……

DataAbstract_config.zip (7.9 KB)


(antonk) #25

Please change the AssemblyName line in the PSQL.NET configuration section to

<AssemblyName Value="Pervasive.Data.SqlClient, Version=4.3.0.0, Culture=neutral, PublicKeyToken=c84cd5c63851e072" />

This should do the trick


(Alan Olson) #26

Thanks Anton - that seems to have worked with ConnectionTester. will test next with SM
Much appreciated.

Alan


(Alan Olson) #27

OK, this worked in SM/connection too…to a point. It connected, it showed folders for tables/views/stored procedures…but no table defs were generated. Is this done differently for ADO drivers compared to ODBC? If I remember correctly, once I first made my odbc connection way back when, the table defs were generated right away via SM/CM

alan


(antonk) #28

That’s a big step forward actually - the DB driver is loaded and works. Now we need to fine-tune its definition to get the rest working. Unfortunately this part I cannot do locally because I do not have a running Pervasive server. So some part of the work will fall on you.

What exactly do you mean by ‘table defs were not generated’? They weren’t displayed in DASM or something else?


(Alan Olson) #29

It connected to the server, it showed three folders - tables/view/stored procedures - but there were no entries in any of the three folders. All i’m concerned about are the tables of where there are many…but nothing was displayed at all.


(antonk) #30

Could you modify the connection tester by adding this code between connection.Open and connection.Close ?

				connection.Open();
				// ADDED
				var schema = (connection.ActualConnection as System.Data.Common.DbConnection).GetSchema("Tables");
				Console.WriteLine("Known tables: " + schema.Rows.Count);
				Console.WriteLine("Column names: ");
				foreach (System.Data.DataColumn item in schema.Columns)
				{
					Console.WriteLine("  " + item.ColumnName);
				}

				var schemaDA = connection.GetTableNames();
				Console.WriteLine("GetSchema result: " + schemaDA.Count);
				// ADDED
				connection.Close();

This code calls the same API that Data Abstract uses to fetch table names (here is a direct call via ADO.NET connection and a call via DA connection).

Please run the code and post here its results (there is nothing specific to your database).

This will allow us to find out if the database driver itself implements the required API


(Alan Olson) #31

here is the output.

C:\alan>connectiontester
Known tables: 79
Column names:
  TABLE_CATALOG
  TABLE_OWNER
  TABLE_NAME
  TABLE_TYPE
  DESCRIPTION
GetSchema result: 0
Connection test passed

(antonk) #32

So for some reason table schema info is being filtered out by DA. Please add this code next to the previously added code:

				foreach (System.Data.DataColumn item in schema1.Columns)
				{
					Console.WriteLine("  " + item.ColumnName);
				}
				for (int j = 0; j < schema1.Columns.Count; j++)
				{
					Console.Write(schema1.Columns[j].ColumnName);
					Console.Write("||");
				}
				Console.WriteLine();

				for (int i = 0; i < 5; i++)
				{
					for (int j = 0; j < schema1.Columns.Count; j++)
					{
						Console.Write((schema1.Rows[i].ItemArray[j] ?? "").ToString());
						Console.Write("||");
					}
					Console.WriteLine();
				}

It will dump to console several first lines of the schema1 dataset.

Please note: Dumped data will contain actual table names from your database. If you do not want disclose them then please send the resulting output to support@

It will greatly help me to understand what’s going wrong there

Thanks in advance


(Alan Olson) #33

here is what I see if I pasted it in the right place…

C:\alan>connectiontester
Known tables: 79
Column names:
  TABLE_CATALOG
  TABLE_OWNER
  TABLE_NAME
  TABLE_TYPE
  DESCRIPTION
GetSchema result: 0
  TABLE_CATALOG
  TABLE_OWNER
  TABLE_NAME
  TABLE_TYPE
  DESCRIPTION
TABLE_CATALOG||TABLE_OWNER||TABLE_NAME||TABLE_TYPE||DESCRIPTION||
LPV8OE||||adchanges||TABLE||||
LPV8OE||||adcharges||TABLE||||
LPV8OE||||adexec||TABLE||||
LPV8OE||||adfiles||TABLE||||
LPV8OE||||adheader||TABLE||||
Connection test passed

The LPV8OE is the database name. The next (adchanges, etc) are the table names. It appears to be retrieving table names just fine.

what’s next?

alan


(antonk) #34

Try to use this connection string:

PSQL.NET?Server=btrieve;Databse=LPV8OE;

DA will be smart enough to convert this string to a database specific one and as well it will be smart enough to extract filter values to properly get schema data like table names.

Next Beta build of Data Abstract will better adapt to the situation that caused excessive schema info filtering (that’s a VERY corner-case specific issue that happened here).


(RemObjects) #35

Thanks, logged as bugs://81037


(Alan Olson) #36

When could I expect s new build that addresses this?


(antonk) #37

You do not need to wait for the build. Just provide a proper connection sting and everything should work already.


(Alan Olson) #38

Using that revised connection string seems to work for connectiontester, but in SM it fails. I see the following going through the new schema wizard:


(antonk) #39

If the connection tester did show you a non-zero result here:

Console.WriteLine("GetSchema result: " + schemaDA.Count);

then the issue with Schema Modeler is caused with something else.

Could you
a) Set the ConnectionTester project properties Build -> Platform Target to x86 and re-run it?
b) Start the Schema Modeler, define the connection in its Connections Manager and then expand the Tables node there? In case of any exceptions there will be way better report displayed.

Other possibilities are

  1. Create as stripped-down copy of your DB and somehow expose it to me over Internet?
  2. If that’s not possible then please send a mail to support@ . I’ll create a build of Schema Modeler that will crash on this screen instead of swallowing exceptions and displaying the ‘Cantot retrieve data…’ label

(RemObjects) #40

bugs://81037 got closed with status fixed.


(Alan Olson) #41

Rebuilt connection tester as 32 bit, and saw no change.