Subject RE: [IBO] Edit fields in grid supplied by Stored Procedure
Author Helen Borrie
At 10:39 PM 12/10/2005 -0400, you wrote:
> > >
> > >I have a IB_Grid that I am populating from a stored procedure,
> > >I use the updateSQL to update the underlying table fields when
> > >they are edited. But I have a couple of problems:
> > >
> > >1. When a field is edited and the user moves to the next record
> > >the changes they made to that field vanish from the screen.
> > >They where made to the underlying files, and a refresh will cause
> > >them to reappear. How do I get them to stay?
> >
> > Don't use Autocommit. Wait until the user has finished doing
> > the updates
> > s/he wants to do, then commit the changes as a whole. The
> > reason is, of
> > course, that a selectable SP has no linkage whatsoever with
> > the underlying
> > tables. It would have to be executed afresh to deliver the
> > updated rows.
> >
>
>That sounds like it would work, but that would mean that the
>changes will not get posted until the user exits the screen,

Just call Post. This is the method that causes the update/insert/delete to
occur. I have to confess that I really don't know what you are talking
about here...

>or I will need to setup a timer to fire the commit in a timely
>manor.

Commit and post are NOT the same thing. Post is a method of the statement
object. It sends the current request to the server. You can post lots of
statements, without committing. Commit is what you do to a transaction (or
rollback, if you have a reason to).

> If it's a non-nullable
> > column in the
> > database, existing rows should not be coming up with nulls. If it's
> > nullable in the database and you are forcing it non-null in the
> > application, then you've got a different problem, insofar as
> > you have one
> > rule defined in the database and a conflicting rule in the
> > application. Not desirable....
>
>We are editing data, the field is non-nullable in the db how do
>I make the program IBOBjects checkbox in the grid realize that
>it is non-nullable and stop allowing it to change to null?

If it was a real dataset, you wouldn't have to tell IBO, because it would
know (from the metadata it receives on preparing the statement) whether the
column is nullable or not. But a select procedure is a virtual dataset, so
there is no metadata to get, other than the types and sizes of the
arguments. So you should certainly make your application treat the data in
such a way that it won't cause exceptions when posted to a table. Hence
the absolute need, in this case, to enforce a value for inserts.

Helen