Thanks a lot
It looks much neater now
Nick
"Rauf Sarwar" <rs_arwar_at_hotmail.com> wrote in message
news:92eeeff0.0210061203.24ab0d79_at_posting.google.com...
> "Nick" <aroughguy_at_nsp.toughguy.net> wrote in message
news:<QoQn9.12427$Sr6.404471_at_ozemail.com.au>...
> > I'm using Form Builder 6i on WinXP Pro
> > Couldn't find anything on row_flag or row_new in any Form Builder Help
> > topics
> >
> > Can you be more specific?
> >
> > As said my way works fine, my concern is only on performance when data
grows
> > large.
> >
> > Thanks
> > Nick
>
>
> I only mentioned ROW_xxx as a description. Actual value is a Hex value
> and different tools have different ways of doing the same thing. i.e.
> Find out a rows flag.
>
> Even though I am not too familiar with Oracle Forms, I am sure there
> are plenty of built in functions in Forms to do this kind of thing. I
> beleive there is a Get_Record_Property (or similar) function to
> determine the status of current record. It would be either NEW,
> CHANGED etc.
>
> My suggestion,
>
> 1) You should familiarize yourself with Forms thorougly before
> starting any development.
> 2) Familiarize yourself with Client server development. Specially what
> should be avoided in Client/Server development which could impact
> "Performance".
>
> > As said my way works fine, my concern is only on performance when data
grows
> > large.
>
> Indeed. But this logic is flawed.
>
> 1) Why make an unnecessary server call *just* to find out if a row is
> new or it exists on server. This can be easily done on the client side
> using row property/flag.
> 2) This may not be an issue if table is small and there are few users.
> This could have impact if a table grows and multiple users are trying
> to do the same thing.
> 3) PK based search on the server side could result in data loss. e.g.
> User A adds a new row but have not saved yet. User B adds and saves
> the row with same PK value as user A. User A wants to delete his
> unsaved row. Your PK based server search could delete user B's row
> even though user A has not saved his row yet.
>
> /Rauf Sarwar
Received on Sun Oct 06 2002 - 22:14:09 CDT
