Hi Roger,

I am not a CPWR employee even if a lot of chaps think so, because I try to answer questions on uniface.info.
I'm just a guy who payed for a developer license and pays year-by-year for "support"

Based on my own experiences, it is not the issue of people telling CPWR what they need produce software.
It is the bitter feeling over the years that CPWR doesn't listen to what their paying customers need.
Ever been contacted on an issue one placed on the wishlist??

Seems only if you "motivate" that without this enhancement,you can not sell 500 runtime-licenses, they may move.

Hi RogerW.

think it is about the max size of a (string) parameter in uniface.

But for sure some insiders may have better explanations why and ....

Uli

Hi Uli,

I think you are right. The more data that is added to the existing testentity rows, the less rows are possible to return by the web-service call, ie. there are probably a byte limitation on the returned xml-stream.

I have also tested that calling the web-service twice, the second call will overwrite the Uniface form records of the first call.
activate "TESTSERVICE".GetTestRows("testentity", 0, 10)
activate "TESTSERVICE".GetTestRows("testentity", 10, 10)

So
Whats the exact limitation?
Is this the correct behaviour, seems very messy having to count bytes to get the biggest possible pages?
Will Uniface 9.5 address this problem? See also eg. http://uniface.communityzero.com/uniface?go=2390336
Is it possible to get something similar to retrieve/a with web-services or do you have to start moving to a subentity or dummy entity to get more rows than the limitation accepts?

Regards RogerW.
 

Hi Roger,

I think you ask this kind of questions someone working for Compuware.

In the past I found the best is to talk to your sales people so they can add some magic motivation.

Uli

BTW: there are a lot of hidden sizes of thet kind in uniface (dynamicly generated SQLs must not exceed xyz, ....)

Hi Uli,

yes of course we talk to sales people etc.
But it's even better if many people tell Uniface/Compuware the same story.

Building the "Uniface web" tool is important, but as a part of that it's also important to develop the Uniface communication services model to conform to commonly accepted styles.

Actually it's today very difficult to combine the "Uniface development tool" with "commonly accepted communication services". Perhaps Uniface should consider to adapt to the "Windows Communication Foundation"-model/patterns which itself tries to  conform to commonly accepted styles (knock on wood). This said just because windows is an imortant platform for the Uniface-tool and I'm not sure that you anymore can build anything that is both platform independent and efficient. This would give Uniface a pattern to follow and perhaps helping not to neglect the SOA-architecture.

Today (and tomorrow) we need to share "master"-data among many different software developer companies, meaning that the SOA-architecture will become even more complex (state, transactions etc.).
By the way, I'm very confused that Compuware didn't push there n-tier and xml-communication harder ten years ago, as Compuware then provided similar technics that today is making a breakthrough in other development tools. 

 Regards RogerW.