Re: How to merge 2 customers into 1?

[Robert Rogerson <rogersonra@xxxxxxxxx>]

Keith, just a quick question on committment control.

If committment control is not regularly used, but desired as in the scenario
you described, can commitment control be turned on for the duration of a
process and then turned off again when the process is complete?

Thanks,

Rob

On Tue, May 4, 2010 at 5:15 AM, McCully, Keith (Insurance, Technology
Services) <Keith.McCully@xxxxxxxxx> wrote:

> It would better to group all the updates for a particular customer into
> a transaction with a single commit control boundary. That way, if all
> updates for the customer worked then go ahead and commit the updates to
> the database but, for any failures, rollback all the updates and proceed
> to the next customer. So, either way, you will have all the records for
> each customer in the same state. Also, if failed, write a line to an
> error log to highlight the error and assist recovery although a manual
> recovery on up to 30 files seems painful!
>
> It would also be possible to run as EOD background job rather than
> interactively - depends how quickly you want the update.
>
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of David FOXWELL
> Sent: 04 May 2010 08:17
> To: RPG programming on the IBM i / System i
> Subject: How to merge 2 customers into 1?
>
> Hi,
> I'm looking for advice and/or opinions on this method :
>
> A user can display a list of clients sorted by name and date of birth in
> a subfile. If all the names and dates of birth are equal for two
> clients, the user has an option that will merge the 2 clients into one.
> This means that one client number will become obsolete. There are about
> 30 different files in which the obsolete client number is replaced by
> the remaining client number. After confirmation by the user, the program
> loops through a file that contains the files to be updated. For each
> file information is extracted to create and execute an SQL update. If an
> error occurs on the update, a message will be displayed to the user but
> the program continues the updates on the remaining files. The user will
> see at the end that at least one file update failed. We've just had a
> case where this happened, and I must say I am rather surprised at this
> method of merging the clients in an interactive application, but I am at
> a loss to think of a better way.
>
> I am interested to read how others have resolved this problem.
>
>
> --
> This is the RPG programming on the IBM i / System i (RPG400-L) mailing
> list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives at
> http://archive.midrange.com/rpg400-l.
>
> *** WARNING : This message originates from the Internet ***
>
> The Royal Bank of Scotland plc, Registered in Scotland No. 90312.
> Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
>
> Authorised and regulated by the Financial Services Authority.
>
> This e-mail message is confidential and for use by the addressee only. If
> the message is received by anyone other than the addressee, please return
> the message to the sender by replying to it and then delete the message from
> your computer. Internet e-mails are not necessarily secure. The Royal Bank
> of Scotland plc does not accept responsibility for changes made to this
> message after it was sent.
>
> Whilst all reasonable care has been taken to avoid the transmission of
> viruses, it is the responsibility of the recipient to ensure that the onward
> transmission, opening or use of this message and any attachments will not
> adversely affect its systems or data. No responsibility is accepted by The
> Royal Bank of Scotland plc in this regard and the recipient should carry out
> such virus and other checks as it considers appropriate.
>
> --
> This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.