Reading is not that problem, if you know what kind of results you expect.

Of course, selectdb is perfect for aggregations and similar actions.

Testing the existance of an occ, a retrieve (and $status=0) is best, because no data is fetched/transported as long as you make no assignemnt on fields.

In more complex situations we define views on the database. That is not any more db-independent and you've got parts of your business rules within the view. But having a couple of views which represents the standard situations, is (a) much easier to maintain than struggling through tons of uniface code and (b) faster.

From our expierence writing is in lot of cases a bottle neck, especially in processing data, when you need to write lots of data in already very big tables (and in one transaction). Putting the data e.g. into a temporary table and then with a simple sql-update copy them into the original is definitly faster... Unfortunetly then you are leaving uniface ...

Thank you for the advices.

Regards,Rafa.

Testing the existence of an occ can be done with lowest stress on the database using the LOOKUP command.
This command does not force any data transmission from the database (not even key information).

But you have to note that this LOOKUP works only on the outermost entity (similar to the normal RETRIEVE).

You can not use this for a specific entity i.e. there is no lookup/e

Success, Uli

Dear Uli,

as far as I remember, lookup works not only for the outermost.

It depends on the active entity, (e.g. $entname). So if you use a code sniplet like below, it also work for inner entities ;)

 $collhandle(<myInnerEnty>)->Check_Exist()

partner operation Check_Exist

....

setocc "<$entname>", $curocc(<$entname>)

lookup

if ($status > 0)

    retrieve/a...

....

Best regards

Thomas

Hi Thomas,

what uniface version have you used to test your code snippet against?

success, Uli

Hi,

What do you wants to do ?

Sql/print is dependant of the database and the datatype.

retrieve : find all fields but you can make an update after.

selectdb : select only field who you need and you can't update the database after.

The most efficient is that What you need to do.

Now, hardware and software works rapidely.

Antoine

It´s only for my knowledge, i know that this instructions are for differents things in most case, but in the example:
if we want to do a sql like "select field_a, field_b from table where field_c=x and field_d=y" and not to update fields.
What it´s the most efficient?

Or, if we want to "commit" N rows,
sql "commit","DEF" or commit instruction of uniface?

Regards,Rafa.

The uniface commit statement is translated to the SQL instruction so fast that there is no measureable difference. Same goes for the retrieve & read versus an SQL. Please do not sacrifice you database independence for a difference that is so small. You can measure if you want with proc tracing, you will need to write a loop and do it a lot of times to get a difference in performance.