Hi G?nther, Case independend search ================== the case-independend search is a very very old request (70's) and the most efficient way to support this is the good old MATCHCODE . MATCHCODE=uppercase(FIELD1) in the -trigger. Only this way you can set indices in the database to force in-between searches rather than full table scans. REDUCTION of hitlists =============== An option (already in production) uses different stored procedures and SQL scripts with all kinds of temporary tables to narrow the result-table and than grab these remaining data with uniface. Both scenarios can be used right now. I agree with you totally that in most cases you can write proprietary SQL statements which execute much faster than the old uniface way of collectin data. Success, Uli

you may abuse the WHERE to add some clauses to the SQL statement generated by UNIFACE (it is a very old one as you can see from the 5.2.f: SELECT NAME FROM EMP ORDER BY NAME[5,10] works. Unfortunately uniface (5.2.f) doesn't allow a read order by "NAME[5,10]" So we tried some dirty tricks using the where-clause: read where "text" causes uniface to generate a sql statement like SELECT ... FROM ... WHERE (text) The following strange looking uniface statement builds a hitlist sorted by a substring: read where "0=0) order by NAME[5,10] --" This forces uniface to construct SELECT ... FROM ... WHERE (0=0) order by NAME[5,10] --) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The '--' starts a comment in Informix SQL (as it does in Oracle SQL, I think) and is needed to eliminate the final parenthesis. I hope this will be helpful to someone else. AFAIK, there are some commands to limit the hitlist (to 1 record only) which may be applied here. Alternative: Transfor the entities ti views and put the limitation to the WHERE of the View.

Dear Ulrich, dear readers,

erhmm ... i'm definitly aware of how to tweek the SQL with WHERE (and not with U_WHERE). But actually this is not the point and neither the CLAIM!

The Claim is just to open the UNIFACE NATIVE support for this without having in mind which DBMS you run! George Mockford showed us, how to push the limits with WHERE (look for "Uniface webcast - Web Page Pagination.wrf").

My Claim goes a bit beyond that!

1. I want to be able to just get SOME of MANY occ's! (without overhead)
2. I DON'T want to play tricks on Uniface to archieve this (this will end up in a big mess if the tricks fail on DBMS "xyz")
3. If i want to do multi tier development, then its MANDATORY to have the data in control and not always to get ALL occ's
4. I dont want to do mappings for a unified search string :) (yes, you may call me a lazy bast###, but every DBMS is capable to do it on the fly!)

And while talking about multi tier ... Look, this isn't that funny, if you think it over. Its about declaring the layers right aswell as the data retrievel. Without this, the overhead will become very high!

Presentation tier:

HERE we just get the data from a tier below this! ERGO:

1. We call some Service to do so
2. We don't have the entity in direct access (bye bye stepped hitlist! This is where it starts messing)
3. then it's all or nothing, like in web (remember, most services are self contained => Stateless)
4. The data is delivered in XML, a list or per entity param (as i call it remote entity)
5. depending on how you retrieve the data, you perhaps need tons of DTDs

Maybe i didn't get the real point in doing multi tier but in my point of view PRESENTATION is JUST PRESENTATION, BUSINESS does the thinking and DATA has and delivers the data through the layers. Feel free to put me in the right place if i got it wrong.

What really scares me is a scenrio like this:
In a case like "give me the order lines of customer X" which may be some 10.000 occ's and i only have space for a 30 then i don't want to transfer 10.000 occ's every time for every "ok, give me the next 30!"

... is this the way we have to walk!?

Cheers,

-GHAN-


PS:
I would like to hear MORE OPINIONS on this so don't hesitate and just join in! This is about YOUR FUTURE while doing Uniface development :)

Hi G?nther, as I said before I agree with you that a native SQL statement performs much better than the uniface method will do. But one of the things uniface claims since version 1 is that you DO NOT HAVE TO WRITE SQL STATEMENTS, but you can use many different databases. Consequently, they use only a handful of simple SQL statements and have a concept that each entity MAY reside in a different database (we know that in production environments this is a rare situation). Rather than amending the current read/write/updates, a totally new concept may be more interesting: $XMLSELECT(WHAT,FROM,WHERE,MAPLIST,$PATH) a combination of XMLSAVE and SQL-SELECT - WHAT: a DTD to define the required information - FROM: a list of tables to access - WHERE: a where statement, may use many tables - MAPLIST: a associative list mapping columns to fields - $PATH: database identifier like $ORA, $DEF Benefits: - No need to paint entities for readonly infos - No need to hold the data in 2 hitlists - DTD can be generated from the presentation form Success, Uli

hmm ... i guess the following is already done while using multi tier: >Benefits: >- No need to paint entities for readonly infos ===> i don't paint anything for those: getting them as XML, LIST, HTML. I even decided which fields have to be transferred to me... ;) >- No need to hold the data in 2 hitlists >- DTD can be generated from the presentation form ===> i went away from DTDs while transporting with XML some time ago. SAX rules since its limits are set to 10MB as a max parsed data. Furthermore i only transmit the needed fields. Personally i don't want to take the DB assignment job from Uniface. The .ASN and model have their hand on it and thats fine for me.

looks like I have to amend my description: The statements are all focused on the data delivery part. >- No need to paint entities for readonly infos ===> is meant for the component delivering the data; so we do not have to paint a lot of components only to support different frame-in-frame presentation situations. >- DTD can be generated from the presentation form ===> i used the DTD generated from PRESENTATION forms (UNIFACE) to tell the data-delivery component which fields to return, avoiding non-important fileds. The "generate DTD" is just to make life easier and have the modifications only in one place.

Did somebody see the Film "TITANIC" in the newer version with Dicaprio and Kate Winslet?! After the ship has sunk some rescue boats circle around throug the mist, searching for survivors. And the man in the front of the boat shouts out : "... IS SOMEBODY ALIVE OUT THERE!? ... " Some days i feel the same, when i "circle around" in here :) And in addition to this topic here i see myself sitting in such a rescue boat shouting to YOU: " ... AM I THE ONLY ONE BUGGING AROUND WITH THE HITLIST ISSUE? ..." Let me carve out the problem once more: 1) ANNO DOMINI 2009- Compuware will launch RIA at the end of the year, but still the stepped hitlist is closed for pagination. 2) This affects EVERYBODY who uses: - multi tier development - USP / DSP - SOAP / Webservices 3) dynamic systems need dynamic data to turn Uniface to be up-to-date and ready to enter the RIA world ... 4) It's up to US (the community ... yes, this is you, you and you aswell as me) to get this issue off the road! If you aren't affected by now, this could change very fast! So if you find this idea "whatever", then do me a favour and simply reply your thought as a reply to this post. Don't hesitate to simply reduce your reply to ONE WORD if desired (e.g. "CRAP", "OK!", "GOOD", "BAD" ...) By doing so i could figure out how many people have read this. Thanx in advance -GHAN-

Hi G?nther, you are correct that UPPER/LOWER can be done "on the fly" by each database. But my point is: only with MATCHCODE you can build an index in the database which REALLY speeds up the case-independend select process. Uli