At 12:00 PM 26-01-02 +0000, you wrote:

>Hello Helen (and all the other people) !!!
>
>You said me that the way I worked was redundant, but I think you
>don't understand me what I want to do (or I don't explain good).
>
>Now I have reduced the problem using only IB_QUERY (and the UpdateSQL
>property).
>
>If I wan't update the actual record, it's sufficient to do:
>
>IB_Query1.Edit;
>IB_Query1.fieldbyname('name'):='Changed record';
>IB_Query1.post;

You need this approach for interactive editing, i.e. things the user types in or changes by some other means. So the only time you would assign a value using FieldByName() would be when the user has edited some visible fields and you want the application to edit a field which she can't see.

>But I want to update a record different that the actual, I think I
>need first locate the record (LOCATE is slow), and then do the
>update, isn't it?

It depends. If you want the *user* to edit that different record, then you would provide search capability and let her search (or browse, yuck) until she finds the record she wants.

If your application wants to update a record which the user doesn't select, then you would use a separate IB_DSQL component with parameters. You would not use a dataset for this at all.

>Please, could you help me about the way to work.
>
>I wan't update a LOT of records, and it's important it's no be slow.

You will have to provide more information about how these records would be selected...but, the fact remains, that if the update is not being done interactively by the user then you would not have your application perform it in a client buffer.

>Really I don't need to see the information until all the changes was
>made. I worked with IB_QUERY and the UpdateSQL property because was
>the first idea.
>
>I also has proved using the IB_CURSOR to do the search (more more
>quicky), buy I have the same problem with the EDIT when I want update
>the results. I don't know if I have to use 2 cursors or is possibly
>with the same once time locate the record.

No. If you just think of the issue like this - datasets are for interactive users. Inserts, updates and deletes are driven by the user, typically in a hunt-and-pick (browser) or searching interface; These methods operate on one record at a time - the currently selected record.

Non-interactive operations use DML statements. The IB_DSQL component implements TIB_Statement without the overhead of a dataset so it is very, very fast. It can be any DML statement, including a call to a stored procedure which performs DML.

If your interactive users are looking at a dataset selected from the same table, your application will pass parameters from the currently-selected record across to the DSQL statement. The users will see the results as soon as the dataset is resynchronised with the underlying table. The method you choose for resynchronising depends on several factors, like whether the DML was performed in the same or a different transaction, what isolation level you use for the transactions, et al.

regards,
Helen


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org
_______________________________________________________