Subject | Re: [IBO] Why do two queries work differently |
---|---|
Author | stevewe2 |
Post date | 2003-10-10T22:58:50Z |
Thank you very much, Helen. The GeneratorLinks property was the
ticket. And your remarks about the KeyLinks provided additional
insight as to why/how IBO works. I sure wish I had time to really get
to know IBO instead of playing beat-the-clock while in development.
It would be time better spent to work smarter. Do you ever offer
training beyond what you may do at BorCon or the FB get-togethers?
Thanks again -- you've made my weekend possible, Steve
ticket. And your remarks about the KeyLinks provided additional
insight as to why/how IBO works. I sure wish I had time to really get
to know IBO instead of playing beat-the-clock while in development.
It would be time better spent to work smarter. Do you ever offer
training beyond what you may do at BorCon or the FB get-togethers?
Thanks again -- you've made my weekend possible, Steve
--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> At 04:11 PM 10/10/2003 +0000, you wrote:
> >I have two D6 DataModules that have the same sort of TIBOQuery
> >component accessing a table the same way. The SQL is the same for
> >both: SELECT Table1.* FROM Table1 WHERE (Table1.PKey = :aKeyCol)
The
> >only difference is that one uses Table1 and the other Table2. All
> >other component properties are the same except that I have to set
the
> >ColumnAttributes property to "PKEY=NOTREQUIRED" for Table1
otherwise
> >I get a Dataset error, PKey is required when I insert a new record.
> >Table2 works fine without that property. The Required property for
> >the PKay field is set to False in both.
> >
> >Also, when the record is posted (having set properties to get past
> >the error noted above), Table1 resets the cursor to the BOF record,
> >while Table2 stays on the inserted record.
> >
> >What am I doing wrong or where should I be looking to correct this
> >behavior, as I'd like to stay on the inserted record?
>
> In the case of the first one, IBO doesn't know the primary key of
the new
> record, so it is "lost" until next time you refresh the whole
dataset (or
> the window in which the new record would appear).
>
> In the second case, the user must be providing enough data
to "fill" the
> keylinks of the new record, so it knows which one to fetch back
into the
> same positional context.
>
> Is the PK of the first being drawn from a generator? If so, use
> GeneratorLinks, and make sure your trigger tests "if (new.Pkey is
null)
> then..."
>
> Also, have a look to see what the RefreshAction is in each case.
>
> Helen