Hi,
OE11 serverside, java clients using java-proxies, and a progress CHUI client. I would like to provide the java-client (and the CHUI client) with info about which filter-fields can be used before a fetch-action is done. These filter-fields should result in picking up the right indexes in tables in the database. Maybe an xsd with index-info could be used. For a prodataset you can 'import' an xsd using the read-xmlschema method. Is there something like read-xmlschema for the prodatagraph/ProDataGraphMetaData object or have you developed something for that and want to share? Or do you have another/better idea to provide clients with this info?
Regards, Stefan.
Why do you need dynamic schema there?
And even if you need this to be dynamic I guess the schema (and probably data as well) is generated by the ABL back-end and seems like it is a dataset in the first place... why don't you simply use datase-handle output parameter to pass that to both CHUI ABL client and Java?
Hi Marian,
I'm a java-dummy, the java-client is programmed by someone else in the team. Again another here suggested to do it what I tried to explain with an xsd, if it can be done in a more simple way I would be glad to hear. Maybe I have to explain a bit more: in my java-client I select the maintain orders screen. No data are presented yet, but I want the right filterfields to be shown above the empty grid(s). I only want filters that are supported by indexes. Do you propose to do an appservercall to get this index-info to build the client-screen?
Regrds, Stefan.
Stefan, I guess the only place that can give you that kind of information is the back-end so it has to be some sort of appserver call to get that or might follow the ORM path and 'export' the database schema in a way your client can make use of... reduce the number of appserver calls but need to keep the schema information in sync.
Either way you can pass that data as a dataset or XML, for ABL CHUI client probably a dataset is the best thing but for Java client you'll have to turn that info in some sort of an object... jaxb was mentioned on peg, I use simplexml for that (because it's simple right).
Although what are you trying to do might look legitimate from the database developer perspective might not be what the user want and need... and sometimes, if not always, the users knows better since they are using the damn thing, we just have to catch-up with them and learn how they actually use the application and improve the performance when needed instead of restricting functionality
Nevertheless, as a theoretical discussion... what fields will you consider as valid for filter operations? In an OLTP, especially Progress, the indexes tend to be most of the time composed indexes, with highly repetitive occurrence of 'primary key' fields in many of them with added extra fields. You consider valid all fields that are part of a index, only the first entry in the index, think any of the two options could lead you to where you think you want to go?
Thanks Marian,
Good points, we will discuss them. If something interesting comes out I'll post it.
Kind regards, Stefan.