Critical item update isn't always an option. If you have sorted chains with
extended sort keys, CIU will put them out of order. Use with caution.
Meanwhile, put-before-delete should be safer -- didn't some of the wise ones
call it "best practice" years ago? If something crashes at the wrong time
(and you don't have enough other recovery mechanisms in place) you'd rather
have two detail records than zero, because you can always figure out later
which one you need to delete.
Dave ("wouldn't have a clue what you should do, just pointing out potential
issues") Powell, MMfab
----- Original Message -----
From: "Johnson, Tracy" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, February 24, 2010 10:01
Subject: Re: [HP3000-L] Delete Before Put or Put Before Delete
Isn't that just a subset of choice #1 anyway, changing the source code?
Tracy Johnson
Office 1-757-766-4318
[log in to unmask]
> -----Original Message-----
> From: HP-3000 Systems Discussion
> [mailto:[log in to unmask]] On Behalf Of Michael Berkowitz
> Sent: Wednesday, February 24, 2010 12:46 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] Delete Before Put or Put Before Delete
>
> Tracey,
>
> Why aren't you doing an update, especially with critical item update
> available?
>
> Michael Berkowitz
> Project Manager, CGS Application Solutions
> 5530 Corbin Ave Suite 313
> Tarzana, CA 91356-6033
> Direct: 818 635-0816
> Message: 212 261-9610
> Fax: 646 710-1889
> [log in to unmask]
>
>
>
>
>
> [HP3000-L] Delete Before Put or Put Before Delete
>
> Johnson, Tracy
> to:
> HP3000-L
> 02/24/2010 09:09 AM
>
>
> Sent by:
> HP-3000 Systems Discussion <[log in to unmask]>
> Please respond to "Johnson, Tracy"
>
>
>
>
>
>
> The following is rhetorical, no answer required.
>
> For years and years we've had an application in an Image database.
> Users happily enter data and the program does its thing. Put
> is entered
> sometimes before the Delete of the prior record, of course this is so
> microscopically fast Image doesn't care. I mean what the hell, it's a
> Detail Set.
>
> Years pass by...
>
> We add some 3rd party applications* to the machine that captures data
> entry into a MSG file so a script can read it and populate
> SQL tables on
> a PC based server. This seems well and good when capturing data from
> Image Masters. However when it comes to capturing data from
> Detail data
> sets. In the grand scheme of things, sometimes the captured
> Put arrives
> before the Delete. While Image doesn't care, SQL does,
> because it says
> "No, no, no, I'm getting a duplicate record that's already there. I'm
> not going to let you do that!"
>
> A) We examined the record in the captured MSG file and Lo!, the Put
> *DOES* come before the Delete.
>
> B) Then we examined an Image log record, and in the order of events
> logged and *YES*, the Put comes before the Delete.
>
> Anyway our main application is still happy, it still runs.
> But it looks
> like we may have to do one of two things, both of which are messy:
>
> 1) Go into our FORTRAN code, and change order of events so that the
> Delete is done before the Put. This can be really ugly,
> because it has
> probably always be done this way in all the library Include calls.
>
> 2) Use a big stick in our SQL definition, so that every field in the
> record is part of a Key, so that when it attempts to Put in a
> record, it
> won't find a duplicate, because by definition, the record will be
> different. Then it will happily do the Delete that follows.
>
> What would you do?
>
> * (No this is not a guessing game what the 3rd party application(s)
> is/are.)
>
> Tracy Johnson
> Business Analyst
> Measurement Specialties, Inc.
> 1000 Lucas Way
> Hampton, VA 23666
> Office 1-757-766-4318
> [log in to unmask]
> www.meas-spec.com
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>
>
> NOTICE OF COMPANY CONFIDENTIALITY
> This e-mail, and any attachment to it, contains company
> confidential and/or privileged information intended only for
> the use of the individual(s) named on the e-mail. If you are
> not the intended recipient, you are hereby notified that any
> disclosure, copying or distribution of this information or
> the taking of any action in reliance on the contents of this
> e-mail transmission is strictly prohibited. If you have
> received this e-mail in error, please notify the sender by
> telephone immediately, and/or immediately return it to the
> sender, and delete it from your system.
> Thank you for your cooperation.
> * 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 *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
