Open Client Prodataset error with more than one table.

Posted by Michael Brandt on 21-Nov-2016 16:22

I am attempting to use the Progress.o4glrt.dll to retrieve Prodatasets into C#.net.  I successfully used that following example to retrieve prodatasets with a single table:

http://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dvnet/adding-the-prodatasetmetadata-object-with-its-da.html#

However, as soon as I add a second table, I get the following error:

ERROR condition: Remote mismatched fields or mismatched BEFORE-TABLE attribute for temp-table parameter or dataset member parameter. (12324) (7211)

I have run each table independently in the prodataset, and each returns rows as expected.  When I include both tables in the metadata at the same time, and add the relation code as follows, I get the above error:

ProDataRelationMetaData relation1 = new ProDataRelationMetaData("UsrRel", 1, 0, 1, "user-id,user-id");

md.AddDataRelation(relation1);

I have adjusted the parent and child indices, and also tried including each table's index in the TempTableMetaData.  No luck on either approach.  It appears I need to provide some piece of missing information, however it's not clear from the documentation or the error message what I need to include.  I would appreciate any guidance from someone who has managed to successfully use the Open Client with Prodatasets containing multiple tables.

Thanks, Michael 

Posted by Brian K. Maher on 23-Nov-2016 14:58

Michael,
 
The two types of ordering are _order order and _rpos order.  Over time, changes to tables (add or remove fields, applying incremental .df files, manually changing the _order field – it defines the order that fields are displayed in when doing something like “display customer”) can end up where the _order and _rpos values, when sorted, do not match up (i.e. fielda has _order = 20 and _rpos = 5, fieldb has _order = 30 and _rpos = 3, etc).  This has an effect when passing temp-tables across the wire because, if I remember correctly, _rpos is used to define the field order when transferring the data (it could be _order too, i haven’t needed to remember that in a long, long time). 
 
You can see the values in the Data Dictionary by looking at each fields “Order #” and “Position” fields.
 
Most people define an include file which defines the fields to be used in the temp-table definition.  This gives you one place to make changes and removes any issues related to the internal ordering.
 
Brian
 

All Replies

Posted by Brian K. Maher on 22-Nov-2016 04:32

Michael,
 
Are you not using ProxyGen for this?
 
Brian

Posted by Michael Brandt on 22-Nov-2016 07:21

No, I was advised not to use proxygen, and just code this directly.  Also, I'm on 10.1C, which means I don't have access to the JSON methods, otherwise I would simply serialize the prodataset to a string and pass it.  I suspect I'm missing something very simple, in order to add a second table to the prodataset on the client side, but I don't know what it is...

Posted by Brian K. Maher on 22-Nov-2016 07:26

Hi Michael,
 
That is Interesting, especially since ProxyGen is meant to hide all of the nasty behind the scenes stuff and give you nice simple layer upon which to call things.
 
This is going to be more complex than you think.  Please open an official support case for this.
 
Brian

Posted by Brian K. Maher on 22-Nov-2016 07:26

Hi Michael,
 
One other thing, if you are willing to serialize to JSON ... why not just serialize to XML instead (which is in 10.1C) and pass that as a LONGCHAR? 
 
Brian

Posted by Michael Brandt on 22-Nov-2016 08:34

Yes, I might have to consider the xml option.  But I was really hoping to pull back the tables directly into datasets on the .net side.  I also ran a test this morning and discovered I get the same message if I output two temp-tables.  If I output either temp-table individually, I can successfully return the data, but as soon as I add a second temp-table, I get errors.  So both tables in a prodataset creates the error, and both tables returned by themselves creates the error, but either table returned by itself is fine.  It's not clear what I am missing.

Posted by Brian K. Maher on 22-Nov-2016 08:44

Michael,
 
A couple of comments ...
 

1)      If you are using the OpenAPI then support can help you.

2)      If you are coding to the low level dynamic API then you need to be aware that we do not support this.  The dynamic API is not documented and can be changed by us at will.

3)      If you want a better chance at someone here helping you then you need to provide your code or enough of the code for us to see everything that is going on (both client side and server side).

 
Brian

Posted by marian.edu on 22-Nov-2016 10:00

Brian,


would you care to elaborate on that ‘low level dynamic API’? I’m not aware of anything like that, if it’s an API then it’s public by my definition else should be ‘protected’ and not made available to mere mortals developers like us :)

@Michael, OpenAPI works just fine (most of the time) so no idea who gave you the recommendation to skip proxygen in the first place but I can only second that ;)

I get you’re trying to pass a dataset as input - or in-out, would you care to share the signature of the procedure you try to call into and definition of dataset as well as code you have to create the metadata on the open client side? 


Marian Edu

Acorn IT 
+40 740 036 212

Posted by Brian K. Maher on 22-Nov-2016 10:22

Marian,
 
By low level dynamic API I mean the undocumented classes, etc that are used when proxies are generated.  If you set the option to leave the generated C# code hanging around you can see this stuff and it is also part of the Progress.o4glrt.dll assembly and can be seen via a class browser.  We do not document these classes nor are there any plans that I am aware of to document them.  We consider them as an internal implementation and use of them by customers is not supported.  Can you technically invoke them?  Sure.  But don’t expect any help if you screw things up.  The OpenAPI is a wrapper over the dynamic API which is supported and is the correct way to use Open Client without generating proxies.
 
Brian

Posted by Michael Brandt on 23-Nov-2016 07:07

The api I am using is the set of methods in Progress.Open4GL.Proxy. It is documented here:

documentation.progress.com/.../index.html

So I was able to solve my problem.  It turns out that the first table in my prodataset I was defining "like" the original table in the database.  Apparently there was some configuration on this table that I am not aware of how to code for on the .net side.  The remaining tables did not have this problem.  To solve the problem, I simple created the progress temp table and itemized each of the fields "like" the corresponding field in the database.  This meant I was only capturing the fields and not the characteristic of the underlying table that I couldn't code for.  If I get some time I will try to compose a blog post with additional examples since the Progress docs only contain one abbreviated example.

Thanks everyone for your comments...

Michael

Posted by Brian K. Maher on 23-Nov-2016 07:26

Hi Michael,
 
You are using the documented and supported OpenAPI.
 
The LIKE phrase can cause issues because it orders the fields in the temp-table differently than you would expect.  The best approach is to manually define the temp-table (this is what most of our tools do).
 
Brian

Posted by Michael Brandt on 23-Nov-2016 14:42

Thanks for that observation.  I'm new to Progress and just ordered the fields as they printed in the DB viewer, but they certainly could have been assigned different ordering.

Michael

Posted by Brian K. Maher on 23-Nov-2016 14:58

Michael,
 
The two types of ordering are _order order and _rpos order.  Over time, changes to tables (add or remove fields, applying incremental .df files, manually changing the _order field – it defines the order that fields are displayed in when doing something like “display customer”) can end up where the _order and _rpos values, when sorted, do not match up (i.e. fielda has _order = 20 and _rpos = 5, fieldb has _order = 30 and _rpos = 3, etc).  This has an effect when passing temp-tables across the wire because, if I remember correctly, _rpos is used to define the field order when transferring the data (it could be _order too, i haven’t needed to remember that in a long, long time). 
 
You can see the values in the Data Dictionary by looking at each fields “Order #” and “Position” fields.
 
Most people define an include file which defines the fields to be used in the temp-table definition.  This gives you one place to make changes and removes any issues related to the internal ordering.
 
Brian
 

This thread is closed