Starting with Uniface 9.6.03 we can set attach property to Hmove/Hsize and/or Vmove/Vsize. This moving ability helps a lot to get rid of those splitbars. Unfortunately, hyperlink does not suport Attach property. 🙁 The same problem is with labels.
Using split bar means, that if user resize the form, all widgets (including hyperlinks and labels) are moved. The same effect can\\\’t be done with attached property.
Since most widgets needs to have an associated labels, these must be moved with the field. It is non-sense to move the field without moving its label.
Uniface driver for Oracle support only version of Oracle 11, but it still uses hint first rows. According to many documents from Oracle, this hint is deprecated as long as from Oracle 9. For example, you can find more info here http://www.dba-oracle.com/art_orafaq_oracle_first_rows_sql_optimization.htm – according to that article: \”Staring in Oracle9i release 2, the Oracle performance tuning guide says that the first_rows optimizer mode has been deprecated and to use first_rows_n instead.\”.
Since this hint first rows is deprecated for such a long time (Oracle 9 is not supported by Uniface 9.6), why the new driver does not use the recommended hint first_rows_n instead? It seems to be really much much faster and much better than the old one. We need Uniface to support newer oprimizer mode first_rows_n (and all_rows) instead of the old one.
In many cases, the hint first rows caues serious delay instead of improvement. Several tests results in:
select with hint first rows – 1min 40 sec
select without any hint – 0.3sec (all rows is used)
select with hint first rows(100) – 0.3sec
This problem was also discussed with Uniface Technical Support – and there is a registered Bug 30295.
In some situations, we construct our own where for use in the read trigger (it is where for Oracle). But sometimes, the hint first rows results in a long time waiting just to read nothing at all. The time is in minutes (with hint first rows) insted of tenths of seconds (using hint first rows (n)).
Tracing down these problems is quite a complex task. But if Uniface would use recommended hints (OPTIMIZER_MODE) instead of deprecated ones, this problem would never occur.
“The order by clause in read statement is very limited (to specify a field and optionaly desc). We need more complex ordering using power of DBMS itself (e.g. Oracle). This could be similar to u_where vs. where clauses, where “”u_where”” is Uniface and “”where”” is DLMstatement passed “”as is”” to the DMBS.”
Native support for regular expressions (very similar usage like current Uniface syntax strings) while working with strings. Nowadays syntax strings can be used on many places, but it is not good enough for many situations. Using regular expressions would make many validating/searching/parsing strings much easier. Hopefully, POSIX Extended Regular Expression (ERE) syntax should be enough, but something based on Perl regexp (like PCRE) would be a bit better.