|Subject||Re: [IBO] Lock Conflict Problem|
> No. If you work out the data you actually want, I'll try to help with theo.k. here is my example. I have a stocks table Table A( stock_code,
> syntax; but what you are asking here isn't logical without some
> correlation between tableA and tableB. Also, as I understood, it wasn't
> sums you wanted to represent, but averages....
> >if not can you give me an example ?
> Certainly, given a practicable problem description.
and I have another table which keeps the prices, amounts coming in and going
out Table B (amount, price, in-out,...)
I want to show in a grid => Stock Code , Stock Name, average cost price,
average selling price..
> >I tried another way ; put an IBSql component on the form and use it to
> >the averages ( Master detail related) . It is working very fast but thisSorry I mean TIB_query component. I used two TIB_query components with two
> >time I can't see these results on the same grid ( in one line )
> I can't make sense of this, either. Do you mean "an IB_DSQL
> component?" This component is not a dataset, i.e. not usable for
> SELECTs. If you use an IB_DSQL for executing an executable stored
> procedure, you can read any return values in the Fields array after
grids to solve this problem. One is showing the stocks card details and the
other is showing averages and totals. But this happens in TWO grids. I want
to show them in one grid.
> Yes, you seem unclear about how database state changes work. Triggers
> execute upon the POSTING of a state-changing operation. POSTING such an
> operation (if successful) causes all triggers to fire in the specified
> sequence. Once the POST is complete, all triggers have fired.
> "Post" happens at statement level.
> The posted changes are seen only by the transaction that requested the
> post. No other transaction will see those changes until (or unless) the
> transaction is committed; and, even then, only other transactions that
> in ReadCommitted isolation will see that committed work. Commit makesbegan.
> permanent every operation that has been posted since the transaction
> Autocommit is a client-side thing, not something the server does. It
> causes a form of commit known as "commit with retain" to follow
> upon each post. The Commit with Retain (implemented in Delphi by thecommit,
> CommitRetaining method) causes a new transaction to start after the
> without clearing the resources of the preceding transaction. It was putThank You Helen. It is more clear now.
> there by Borland to make transactional database operations appear like
> Paradox (which isn't transactional). It has its benefits but should be
> used conservatively.
> ServerAutocommit is something different again, with a specific use when
> creating metadata, and should be avoided for interactive applications -
> keep it set false.
avast! Antivirus: Giden mesaj temiz.
Virus Veritabani (VPS): 0525-2, 22.06.2005
Test zamani: 23.06.2005 11:04:28
avast! - copyright (c) 1988-2004 ALWIL Software.