Subject | RE: [IBO] Edit fields in grid supplied by Stored Procedure |
---|---|
Author | Helen Borrie |
Post date | 2005-10-13T05:23:38Z |
At 10:39 PM 12/10/2005 -0400, you wrote:
occur. I have to confess that I really don't know what you are talking
about here...
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).
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
> > >Just call Post. This is the method that causes the update/insert/delete to
> > >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,
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 timelyCommit and post are NOT the same thing. Post is a method of the statement
>manor.
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-nullableIf it was a real dataset, you wouldn't have to tell IBO, because it would
> > 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?
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