I am planning to run a mixed environment consisting of an Oracle Database, with some GUI screens running on Progress through Oracle Data Server and a batch job coded in Java running directly towards the Oracle DB.
My question is how to handle the progress_recid when when coding in Java. The progress_recid is handled automatic when running from Progress, but what if I insert a row in Java? How can I retrieve the "next" progress_recid to use? What happens if I delete a row and the progress_recid sequence is broken?
I have not found any documentation on this and hope somebody could help me.
Have a look at ROWID in the Oracle Data Server documentation.
The same goes with a Progress database. RECID is supported mainly for backward compatibility although, I think, it's still used in the schema files.
What's the Progress version ?
BTW what's the reason for the setup ? why not use a Progress database and JDBC if it's needed.
Thanks for your reply. I still does not think that this covers my questions. I need to know:
1. How can I obtain a new progress_recid when inserting a new row via Java/JDBC
2. What happens if I delete a row and the recid sequence is broken?
I have read the documentation and can not see that it covers these questions.
The reason for running an Oracle database is that we are migrating away from Progress, but are forced to run the Progress GUI in the migration phase.
So, what lapse in judgment is
responsible for that decision?
The progress recid is not a sequential number. It is a binary combination of the block number and the record's offset within the block. If there are unused slots in the block, there will be unused recids. Also, if you delete records from your database, the free space will be reused, so your newly created record will not always have the "highest" recid.
With the Oracle Dataserver, there is an extra field in each table that holds the recid. If you create a record without going through the Dataserver, this field won't get a value. The question I have to ask is: do you need it? If you don't use the recid function anywhere in your Progress ABL code, this field will never be used.
One of our customers decided to create the tables directly in Oracle and didn't even create the recid fields and they work very happily through the Dataserver.
Possible solutions to your problem:
- you could write your Java code to access your existing database update logic through the Java Open Client functionality
- if you use the recid function in your ABL code, you could change them for ROWID functions (NOTE: this returns a different data type) and forget about the recid columns
Let us know if you have further questions.
The progress_recid values should be grabbed from the sequence name _seq.
The progress_recids do NOT need to be sequential - they are just there to ensure progress uniqueness, so do nothing when deleting a record.
As one of the other replies points out you could also adjust your Progress code to no longer required progress recids - note that this can be a tricky task. For starters you should have at least one unique index on all your tables (any decent table should anyway) and then you will need to check for recid use, also be careful when using rowids (as replacement for recid) in can-find functions, these have sometimes broken down on us.
Background: we removed progress_recid from our SQL Server database, on Oracle we've still got it sitting there.
I will not be using the recid directly from any code, but I thought the GUI applications "generated" by Progress relied on these, to be able to navigate forward and back in e.g. table grids?
All other code (except GUI) accessing the data will be Java directly towards the Oracle database, and will not use the recids...
Message was edited by:
Stein Rune Risa
Anyone who know this? Does Progress rely on values in progress_recid to be able to scroll forward and backward?