Re: Check previous record for duplicate field and rename

On May 25, 2:34 pm, Nickneem <nickn..._at_gmail.com> wrote:
> > You don't.
>
> > Why do you feel a 'need' to display, in a view, data which is not
> > consistent with that in the base tables? This is not merely some
> > aggregate you're computing, you're wanting to alter, in appearance,
> > base table data.
>
> > I can't understand the purpose for this exercise.
>
> > David Fitzjarrell- Hide quoted text -
>
> > - Show quoted text -
>
> David,
>
> There's a 'receiving' credit management application which imports the
> data from the view.
> The duplicate records are skipped during the import so I thought
> changing those in the view would solve the problem.
> Make's sense though a view which is a reflection of the actual data
> isn't the place to do so..
> I guess I have to look at other solutions..
>
> Kind regards,
>
> Mike

It may make more sense to populate a staging table for the credit management application to use as a data source, populated by a PL/SQL block similar to what you've posted earlier. Although I don't see the logic of altering valid voucher numbers, especially for an accounting package.

I would more thoroughly investigate how this accounting software is processing this data; aggregates may be a more suitable solution to your 'problem' (summing totals over matching voucher numbers), however you won't know how to proceed until you understand what is being done with this data.

David Fitzjarrell Received on Fri May 25 2007 - 15:04:17 CDT