There are no such procedures in the TurboIMAGE manual as DBXON and DBXOFF.

However, I think you are referring to the DBXBEGIN/DBXEND/DBXUNDO
procedures?

If so, YES, there is a limit to the size of data held in limbo before the
data is posted back to the data base. These procedures were not designed for
holding millions of entries before writing the data back to the base,
but for the processing of much smaller amounts of logical transactions.

Scenario, for example, might be: DBXBEGIN, DBLOCK (of course), three data
sets get updated by a single incoming transaction which would do a DBPUT to
setA, DBDELETE from setB, and a DBUPDATE from setC. The DBPUT is
successful, as is the DBDELETE but the DBUPDATE failed (for any reason).
You now have an incomplete, inconsistent transaction. Your program would
call DBXUNDO and then DBUNLOCK. The idea is that everything in the logical
transaction gets updated or nothing gets updated.


I am not certain on what these limits are but you won't be able to process
millions of entries inside a DBXBEGIN/DBXEND structure. Once the internal
file gets full up an automatic DBXUNDO will take place and your Image
procedure will return an error code (can't remember which error code).

An alternative solution is to do DBOPEN mode 3 (exclusive access),
DBCONTROL mode 1 (output deferred) before processing your mega amounts of
data. However, AUTODEFER has to be enabled via DBUTIL first. Don't forget
to backup your data base first as the DB will be toast if the program
aborts for ANY reason. The program abort will leave your data base in an
inconsistent state and a restore will be your only form of recovery.


HTH,
Brian Donaldson.

On Mon, 16 Aug 2004 09:42:34 -0500, Baker, Mike L. <[log in to unmask]>
wrote:

>Forgive me for asking something that is probably listed in the manual.  Is
there a limit to the amount of transactions you can "hold" when using the
DBXON - DBXOFF commands in Image?  We have a detail data set with capacity
of 16 million, would DBXON DBXOFF blow with that size if you did not do the
commit and wanted to back out after all that?
>
>Mike Baker
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *