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 *
|
