At 07:49 AM 04-03-01 -0600, you wrote:

>I am a newbie to IBObjects, but have purchased "Getting Started" and looked at the tutorials and manuals, and can't figure this one out.
>
>I've placed a TIB_Grid on a form and linked it to a TIB_Query and TIB_DataSource, also placed on the form. The query runs against a single table with 4 fields (it is a lookup table for several tables in the database) and is SELECT *. I indicated the single key field ("ID") in the KeyLinks list. Since it is a generator field, I also indicated it in the GeneratorLinks field as "ID=BA_ID" (BA_ID is the name of the generator). I did not indicate any additional SQL.

Good so far.

>I then placed a TIB_Navigator bar and TIB_Update bar on the form, and linked them to the same TIB_DataSource.
>
>1) In order to make the TIB_Update bar work for anything other than adding records (edit, delete), I had to set RequestLive to true. Your support documents seem to indicate that this step is unnecessary.

Oh, I hope not! Setting Requestlive true is the way to tell IBO that you want...well...a live query! No query on a client/server database is ever actually "live", the way a TTable over Paradox is, for example. A lot of the time, you don't want a live query but, when you do, setting RequestLive tells IBO to go ahead and just "do the obvious" when requested to insert, update or delete.

You can also get "live" queries on joined and unioned datasets in IBO; or even use the data in the dataset to perform updates, inserts, etc. on a different table. The UpdateSQL properties (EditSQL, DeleteSQL and InsertSQL) are there for that...meaning you can completely customise your data manipulation (DML is the tag term for all that stuff.)

>2) When I set RequestLive to true and run the application, everything appears to work fine, except I can't delete the records I add in that "session."

That's right...but it's not that you can't delete rows added in the same session. You need to commit the *transaction* in which the rows were inserted because, until you do, they don't get written to the database and therefore they don't exist to be deleted. Use the Isolation setting tiCommitted and CommitRetaining to keep the current cursor open. After a Refresh, you will have no problem deleting the rows you added.

If you don't want to take explicit control of your transactions, set Autocommit to True on your ib_transaction - then the DML will commit when you Post it.

> Yet, if I close the form and then re-open it, I am then able to delete the record.

Well, yes, but this isn't what you wanna do, is it?

>EXCEPT, the generated ID for the record I added in the previous session is always 1 more than it had been at the time of insert!! How is this additional increment getting called?

GeneratorLinks fires the generator and fetches the latest number back into your app. I'll bet you have a before insert trigger on the table, that doesn't check first for a non-null value in the inserted DML.

It should be

create trigger bi_MyTable for MyTable
active before insert
as
begin
if (new.id is null) then
new.id = Gen_ID (myGenerator, 1);
end

>3) What event is thrown when the user changes records in the grid? I want to put the TIB_Query and TIB_DataSource in a datamodule, but need to update the form's statusbar with data from a field from each record (the last update timestamp, last editor, etc.)

There are dozens of events! Have a look at AfterUpdate.

\cheers,
Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________