Bad luck, Helton, no-one is answering you so then you will have to be
content with my "vacation answer".

>I have a form with a TIB_Grid linked to a TIB_Query, where the user enter
>many records. The form also has a button called "Post" and other called
>"Cancel".

OK

>When the user click on Post, all records must be posted to the database, if
>he clicks the Cancel all the records entered must be discarded.

OK

>I do not want a transaction that exists during all the time the user is
>entering the records in the grid

OK

>This is working fine, but i'de like to know if there is a more "ibo
>oriented" way to accomplish this. Without cachedupdtes maybe ?

Maybe, I don't know.

>Any suggestions will be welcome...

OK, so I'm free to use my vivid imagination...

Add two more fields and a generator. Read the next value from the generator
in your application. For every record you add, set one of the new fields to
this value and the other new field to some value representing false. Put a
descending index on the field with your applications generated value. You
may insert and commit for every record if you want to (normally a user needs
several seconds to write the values for each record anyway, so I doubt the
speed penalty would be too big for online applications).

Now, when your user hits post, issue a query like

UPDATE table
SET NewBooleanField = true
WHERE GeneratedValue = :GrabbedValue

If the user hits cancel, simply issue

DELETE FROM table
WHERE GeneratedValue = :GrabbedValue

Now, the only thing you have to make sure, is that whenever you are looking
for already inserted records in the table, you only select those where your
NewBooleanField is true, because you do not know if the others will be
committed or not.

I'm far from certain this is a good solution, and you may be better off
doing it in a similar way to what my boss has done in his main application.
He simply added a timer, and if the registration takes too long time, he
pops up a message like "Your transaction will be terminated in sixty
seconds. Hit continue if you want to the transaction to continue." If they
hit continue, it will take another 15 minutes or so before it pops up again.
It will prevent your users from going to lunch without hitting OK or Cancel,
because if they do, they will discover that their current work is lost upon
returning. However, users are good at quick learning when it comes to losing
work, and after one or two lunch breaks without OK/Cancel, they will have
learnt (and if it is vital information, you may store it in a kind of backup
table rather than just rollback whatever they did and then tell them to go
confessing to the system administrator to get back their current data).

OK, that's it.

Set
-yes, my brain is on holiday too (wonder where I put it?).