I have a sort of complicated process to do. The first part is the parent collection initialization which returns a 4 digit alpha numeric value as the parent key, i.e. "A000". This is done with a cursor inside a stored procedure.
From there, the users will configure children based on type (prototype or manufactured), process and location.
Rather than query the database, can the "next value" for prototypes and manufactured items be stored in a BO field? Sounded like a GUI thing in the BO to me.
Thanks,
_E
RockfordLhotka:
If the next value has to be unique, it probably can't be assured of being right until the data is actually being saved? Or is it unique within the parent, so you know (in memory) that it can't collide during the data save?
If the latter, then you can certainly generate new key values in your object model. But I wouldn't expose the "next value" to the UI - I'd use it within your object model itself. As you add each new child object to your collection, have its constructor or other create method determine the next value and set itself to use that value.
This way the UI never knows how these values get created - they are just already there in the objects.
It will be the latter, unique within the parent. I'm manually locking and granting exclusive rights to the tool Parent object. It sounded so UI, but it is a behavior the tool object has the unique ability to govern as an internal method. I have trouble separating them since I "do it all."
My concern was in storing the values since during creation, they could abort creation leaving the possibility of a number gap which have a tendancy to trigger deeper audits when systems are reviewed by 3rd party auditors. I don't think I can prevent that. Any user authorized can repeatedly click the AddPrototype or AddManufactured button, now we'll know who when and have a target to shoot at during an audit.
I forgot the part about the NVL list in the subject line, but I think I've resolved that. I had several phrases (names) that would resolve to the same value. It turns out to be another overthought imaginary problem. ![Smile [:)]](/emoticons/emotion-1.gif)
Thanks,
_E
Here's what I do in similar situations, if I don't have to worry about child records of the new records until AFTER I save the new records.
Go ahead and accumulate the records in memory and assign them ids if you want. The id values in memory act as a "relative order of creation" id. Before you actually send the list of records to be saved in the database, renumber the ids to remove gaps, then save them.
Naturally, if your new records have child records assigned to them BEFORE you save them, that's a nastier problem to solve. A fairly simple solution to it is to have primary keys and separate "line-number unique keys." The primary key is a meaningless number, the line-number uses the same trick I mentioned above. Because the child records use the primary keys, and the line numbers don't have gaps, everybody is relatively happy. (Including the disk drive vendors who get to sell a few more drives than they otherwise would. :) )
My preferred solution is to beat simple-minded, technically ignorant auditors over the head with a 2x4, but mgmt won't let me.
My preferred solution is to beat simple-minded, technically ignorant auditors over the head with a 2x4, but mgmt won't let me.
When the customer could be the DOD or another scarey monster, a 2x4 may not be powerful enough, nor advised. Because we need traceability on everything, I'm automagically including all the creation stuff so there is a culprit to blame/bludgeon if their clickitis acts up. They want responsibilty, so let the chips fall where they may. It'll also help label stop-gap items that had to be created to let the system catch up to the millions of users still doing it in Excel and expecting direct interaction with an external application. </duh>
I'm an auditor myself, so I'd check: where are these 5 number? Do you have proof of disposal? Did you sell them on the black market and buy that new car for your mistress, uh, I mean "assistant"?
_E
Copyright (c) Marimer LLC