Reuse of temp-table rowids

Haven't heard of such a parameter.

But as temp-tables reside in a local temp-table database (dbi file), my guess is that similar rules apply as with database tables. So ROWID's are expected to be reused. And when passing temp-tables from AppServer to client, ROWID's change as well.

Hi

Thanks Mike. I'll take a look at how we might change this.

Thanks Mike. I'll take a look at how we might change this.

>

The approach AutoEdge uses is at http://communities.progress.com/pcom/docs/DOC-105097 .

The TL:DR version is to use the unique indexes on the temp-tables to construct a key that's unique independently of the rowids. For comparison, the OE Mobile JSDO also creates a unique ID (each table gets an _id field) and in that case it's a number. However, that value has no meaning on the server side, so this may not be an appropriate approach if you care about this across an AppServer.

-- peter

There is no such parameter. Never has been.

You cannot control the assignment of rowids and you cannot predict them either.

A rowid is an encoding of the storage location occupied by a row, along with the id of the storage area where it lives. When you create a row and it is sent to the database or a local temporary table, a rowid is assigned as a side-effect of allocating space to store the row. The storage manager determines where to store the row based on a variety of factors and conditions. The rowid is the result of this allocation operation.

Once created and stored, a row's rowid will not change. When you delete a row, the place where it was stored can later be used to store a different row.

From the standpoint of the application, you should treat rowids as random numbers.

Note that rows from different tables can sometimes have the same rowid. In multitenant environments, sometimes you will have the same rowid for rows in the same table but owned by different tenants.

Hi

Thanks to everyone. I guess I was probably confusing this with another parameter I'd seen before.

I guess the only potential solution to our problem is when we go to an OO ABL. Who knows how that might look but I might be able to override the rowid function on a temp-table to provide myself with a way of dealing with it.

Thanks

Darren

what's the actual problem you need to solve?

I guess the only potential solution to our problem is when we go to an OO

ABL. Who knows how that might look but I might be able to override the

rowid function on a temp-table to provide myself with a way of dealing

with it.

Even in OOABL there is no way to override the ROWID function on a temp-table itself (TTs and datasets are no different in the OOABL). You will need to resolve this yourself in P code or CLS code.

-- peter

What kind of monitoring are you doing?   Do you just need to know if the TT has changed since last access?  I would think there were better ways to monitor that than ROWID.

A GUID field in every record might be an easier solution.

>A GUID field in every record might be an easier solution.

>

>

solution to what?

The initial request?

"storing the rowid of a particular temp-table record in another temp-table"

ROWID's are problematic. OO does not provide the solution he's assuming. Keep it simple, use a GUID as a record identifier.

solution to what?

To a problem which may or may not be the problem which the OP was trying to solve?

I would guess that Mike is guessing that the OP needed to know whether the row had changed and I'm guessing that the issue is knowing whether the table has changed.

sorry Mike, but "storing the rowid of a particular temp-table record in

another temp-table" is not a problem. it is the OP's solution to some as

yet unstated problem.

I would like to know what that problem is. then we can see if we can come

up with a more suitable solution.

Hi

Its a old system that predates adm1 but which is distributed.

We have a temp-table called ttData which has a raw field in it which is used to hold other temp-tables. Multiples of different temp-tables are copied from client to server using this method. So we can pass any amount of data in this way.

Obviously this is before PDS's even existed.

So on the client and server we have a degree of unmarshalling of data. The temp-table is transferred into ttData records. Once unmarshalled we keep track of the exact temp-table record by storing the temp-table rowid in ttData.ttRowID.

So when populating the data back for trsnaport we can put it back into ttData. We have some issues with the rowids being reused which messes things up.

I don't like this but its in several thousand programs. It would have been nice if rowids could have been made unique but a colleague has got around it by addressing the possibility of not being unique and coding for it.

Thanks

Darren

one way to do this is to have a column which is a unique key in the table.

another is to continue to use rowid as part of the key but add something else to the upper bits (which are going to be zeros in temporary tables). a simple counter in a global variable might suffice.

one way to do this is to have a column which is a unique key in the table.

Hence my suggestion to use a GUID.