On Mon, Sep 1, 2008 at 5:58 PM, Sergio H. Gonzalez
<shg_sistemas@...> wrote:

>
> "Sasha Matijasic" escribió
>
> > Ok, so you need to lookup the documentation and demos for ibx components.
> > Basically, study TDataSet descendant and TDataSource classes and learn how to
> > connect visual components (like, TDBEdit, TDBGrid and such...) to them. Google
> > it and you'll find examples and tutorials on the net.
>
> Hi Sasha! I'm very sorry I didn't explain myself better when I posted this
> thread... I do use the IBX components and also the dataware visual
> components in my app. In almost all the forms I use
> ClientDatasets/DatasetProvider. So I have very short read-write transactions,
> and for the small tables I use TQuerys with read-only transactions. I also know
> what databases are. I follow all the normalisation rules in the design...
> Again: I'm so sorry for posting an unclear question.
>
> Only for my base form to do master/detail documents
> (invoices, sales orders, purchase orders, stock movements, etc...) I construct
> the SQL and send it to the database. Actually I'm quite happy with it. I use a
> read-only transaction to read all the tables I need and then I start a
> read-write transaction, execute the script and commit. If the user don't save
> the document I have no need to rollback. And most important (for me) I dont have
> a read-write transaction open while the user is doing the invoice (it may take a
> long time to do it). Anyway... I'm still a newbie!! And probably this is not the
> best way to do it...
>
> My original question probably should have been "how bad is to perform a bulk
> delete (usualy less than 20 and rarelly more than 300) and then insert them
> againg with the (posible) changes". If this is a bad practice I can check what
> records changed and update them and delete/insert the deleted/new records. This
> only happens when the user opens an already saved document modifies it and saves
> it again. Not very often, really.
>
> Sorry... and thank you very much!
>
>

Hy Sergio

I think you should use transactions and commit or rollback at the end, even if
you currently have no need to rollback if the user cancels.

The point is to allow concurrent edits of the same invoice (with its details).
The database will tell you if you commit two concurrent transactions with
conflicting changes.

Just start a transaction when you open your form (as a way of reserving access
to that data and of making sure data does not change while the user has it
in an opened document), make and updates, inserts and deletes you need as
your user changes the invoice and the details, and then commit on OK button
or rollback on Cancel.

If another user has edited the same record before you press OK than your COMMIT
will fail. You should reload the form and instruct the user to try
again. You shoul
also have a look on transaction isolation levels. Databases try to provide
reasonable (but not fail-proof) defaults.

Even if your client needs no concurrent access, this is still the good
and simple
way to do the job, with no unnecessary deletes.

Your attempt to optimize db access by delaying the transaction start
until the user
is ready, and than running into the delete/insert question, looks like
beginner style
to me. As a programmer you have to see not only the details, but also the big
picture. Optimizations, if they concern you (which they shouldn't) can be done
on the big picture only. Half of a programmer's problems are
optimizations at low
level.


I agree this way may not be optimal in cases the user deletes and inserts the
same detail record many times in a row, but still the operations are
only committed
once and this is still the good way to do your work.

Kind regards,
Timothy Madden