Thanks for the response.  Here is the problem.

We are an HMO that makes use of the SSN to uniquely identify a member.  A
new California law going into effect in mid-2004 limits the usage of the
SSN (eg, it cannot be used on ID cards or on explanation of payment
responses).  As a result, we have made the decision to change the SSN to
another number to comply with the law.

I am now in the process of writing a program that will identify all
occurrences of a given Member ID value, and change that value to the
correlating "new" ID number.  This will happen over multiple datasets and
databases, over potentially hundreds and thousands of records for a given
member.  Because of the huge amount of data that must be changed, I
recognize that this cannot be done in a single weekend and am building
into the program the ability to make these changes for groups of members
at a time.

If the program is run off-hours, there's no problem.  For example, we can
run a batch of 100 members through the program, change all their values to
the new correlating ID number, and perhaps it takes an hour.  But if we
run it during OLTP, someone might do a lookup on that member's claims and
only find half of them in the system, because the other half has already
been "changed" to key off the new ID number.  Thus the question, is it
possible to row-level lock all rows in all datasets that pertain to this
particular member, change all of them, then commit all transactions?  The
other applications would not "know" that we are row-level locking unless
of course they tried to access one of the records, and IMAGE denies them.
Perhaps that would crash the other applications--I do not know.

As always, I appreciate the feedback and input.  Thank you.



On Tue, 11 Nov 2003 18:06:03 -0800, Gavin Scott <[log in to unmask]> wrote:

>Well, what do you want to get out of it?
>
>Transaction Management in the form of the DBX functions is easy enough to
>add to a program, and is useful even if only one program is modified, but
>DBX transactions are seriously limited in size so you can't have the
entire
>program run be a single transaction unless it's not doing very much.
>
>Image lacks transaction isolation, so the only way to get some of the
>benefits of transactions is for all users (including readers) to do strong
>locking on everything, so that nobody sees the results of a partial
>transaction (which might get rolled back).
>
>Row-level (a.k.a. item or "predicate") locking is only useful if all the
>programs accessing the data are modified to *correctly* implement this
style
>of locking.  Row-level locking in the presence of set-level locking
>generally just turns the row-locks into whole set locks (or worse).
>
>I'm not sure what you mean by "checkpoints".  Again, DBX transactions are
>size-limited such that partially-committing transactions wouldn't
generally
>be useful.
>
>Tell us more about the problem.
>
>G.
>

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