>in C/S you always stay in the same process so keeping info is a snap.

In C/S used efficiently then you cannot run stateful either. Unless one is using the -ex switch to provide one server for each client, the servers are shared, if you try to run stateful in that respect you get one user locked up behind another user.

.. correct Iain,

but YOU can choose an architecture where you can work statefull and all-in-one-process.

if you use another one (remote services etc.) you have your cost/benefit reasons to so so.

So efficiency is not a abstract value:
If pagination support is your prime concern, you can use stepped hitlists on your client (built-in feature).

In a stateless, multi-process world, you have to use some kind of persistency to achieve the same goal, don't you?

Uli

For Ingo and all other interested in this topic:

The pagination will not be possible for MySQL and SOLID due to the filtering in the ORDER BY setting of the READ statement. Got this confirmed from the support as I did my tests and found nothing.

As this parameter is filtered, there will be no override of statements here.

Therefore I will (once again) raise a Wish to the topic! Adrian, you hear me? This one is directly for you :D

no problem, Iain.

Nowadays, we have so many options for an "optimised" execution pattern with lots of pros and cons.

Especialy if you want to use access via instancenames it's a nice playground (see the discussion from last year).

Rationale: there is an instance named "local_law" in APS we have a newinstance but we may use different components (impelmenting the same API).
The whole application should not bother but activate "local_law".DO_THIS(...) instead of all the if-then-else trouble.

Hi Günther

Keep calm, don't  risk a heart attack. We need you at the next U.B.G.  :-)

A first step from Compuware could be a function which returns to a given UnifAce "profile"  the DBMS specific SQL string(s).

Example

; FLD_1 string       ,  $VAR1$="ABC"
; FLD_2 numeric  ,  $VAR2$=123
; FLD_3 string       ,  user did enter a profile XYZ*

If the READ on TABLE1 looks like

READ u_where "FLD_1=$VAR_1$ & FLD_2=$VAR2$" order by "FLD_3:a"

A function called SQL_TBL_INFO should return the following

READ/prepare u_where "FLD_1=$VAR_1$ & FLD_2=$VAR2$" order by "FLD_3:a"
$WHERE$=$SQL_TBL_INFO("TABLE1","WHERE")
$ORDER$=$SQL_TBL_INFO("TABLE1","ORDRE_BY")

where
$WHERE$="FLD_1='ABC' AND FLD_2=123 AND FLD_3 LIKE 'XYZ%' "
$ORDER$="FLD_3 ASC"

Further, it could by nice to know the SQL-datatypes of fields in a table

$DT$=$SQL_FLD_INFO("FLD_2.TABLE1","datatype")

which results in
$DT$="int"

And so on ...
If I rember right, long time ago  I did put something like this into the whichlist, but who reads it :-(

Ingo

Ingo ... still feeling groovy and yet disappointed. All the stuf WE do for this and how little is needed to make it happen without the hacks. Doesn't feel that good.

And yes, Ingo, a little more access to the DBMS would be nice.

The Wishllist indeed is a strange section aswell as the calculations within! I wonder how the stuff gets rated ...?!

And the next U-B-G? Hmm ... A7 Ausfahrt 121 :) best Traveltime so far from here: 5h15min :D

Hi,

I went the same discussions last year. I discussed with George and for Sql-Server I sent him the following sql that even could be used for several fields making the "key".

"select * from orders where
exists ( select * from (select row_number() over (order by ORDERNO) as row, ORDERNO from ORDERS ) as
ORDERSwithrownumbers where row >10 and row <= 20 and
ORDERSwithrownumbers.orderno=ORDERS.orderno)"

$WhereClause$ = " exists ( select * from (select row_number() over (order by <PagePrimaryKey>) as row, <PagePrimaryKey> from <PrimaryEntity> %%WhereList%%%) as <PrimaryEntity>withrownumbers where row >%%row1%%% and row <= %%row2%%% and ORDERSwithrownumbers.orderno=ORDERS.orderno)"

And this is just Sql-Server.

But I fully agree with GHAN. Uniface/Compuware had (still have?) the chance to build a real nice web development tool. The key to this is custom data-pagination, especially for a product as Uniface that concentrates on business critical applications.
True custom paging should be incorporated into the database-drivers and should be the default way of browsing through records in an Uniface web application.  

Regards RogerW.

Thank you, Roger. I used to work with your solution until i lately found another way. This has been a great help for my paging all the time. And it pleases me to know, that pagination is not only requested by me.

If you like, I have another patch for your MS SQL server paging.

Cheers and a happy new year,

-GHAN-

... couple of years ago (when the dITo initiative was still alive),

I published a pagination solution here on uniface.info using a temp table build up with an sql statement
Composed of an identifier, a sequencenumber and the PK-values.
For better performance on deletion via uniface, I used an UP entity holding the identifier (with cascading delete)
plus some admin information.

Still a very easy way to handle these pagination problem based on the simple:

data preparation
data usage
data cleanup

Methodology (for germans "EVA Prinzip")

Yes, thats what you showed back then, and still this aint good enough to publish for our customers! To do a pagination, even on Microsofts SQL server there is  no need to use temporary tables. I remember doing so in my AS/400 times back then, when i was released to it :D long time ago ...