Looks pretty ugly. Makes me wonder if O/R is appropriate for such things at
all?
Will keep thinking...
Andrus
Shengaout, Misha (MARC) writes:
> I should be able to provide several scenarios by e.o.d. Saturday. For now,
> here are couple crude cases:
>
> 1. Entities INSURANCE_CLAIM and INSURANCE_CLAIM_RECORD have one-to-many
> relationship. Class InsuranceClaimRecord has field "workflowStatus", which
> is determined as the result of the very complex query. Consequently, to
> retrieve the collection of InsuranceClaimRecord-s for the claim we are using
> spLoad_Claim_Detail(vrClaim_ID As NUMBER), which returns the result set
> including INSURANCE_CLAIM_RECORD table and "WORKFLOW_STATUS". There is no
> stored procedure for retrieving the INSURANCE_CLAIM one at a time using ID.
> 2. spMy_Inbox_Claims(vrUser_ID As NUMBER) returns the tabular, read-only
> record set based on INSURANCE_CLAIM with the results of the search. When
> user selects the row in the table, the insurance claim is opened for
> editing. Ideally we would have one-to-one relationship, which would allow to
> navigate easily from MyInboxInsuranceClaim to InsuranceClaim.
> 3. When creating new InsuranceClaimRecord, we have to generate associated
> workflow items, which is done by calling corresponding stored procedure (too
> complex to be done through trigger). Need the event, which would allow to
> add this call for the CREATE event in the same transaction frame.
> 4. When creating new InsuranceClaim results in generating of the
> corresponding workflow, which is encapsulated in spClaim_InsUpd(). This
> stored procedure has the set of fields matching INSURANCE_CLAIM table, and
> does all the workflow generation. Moving it to the trigger is not possible
> for various reasons, so all INSERT and UPDATE operations for InsuranceClaim
> should be done using spClaim_InsUpd() stored procedure, with the fields of
> the class mapped to the fields of the sp. The generated ID is always
> returned in the OUT recordset.
>
> That's it for now. Shoould polish it over the next couple days.
>
This archive was generated by hypermail 2.0.0 : Wed Oct 23 2002 - 18:45:01 EDT