> No. If you work out the data you actually want, I'll try to help with the

> 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.
>

o.k. here is my example. I have a stocks table Table A( stock_code,
stock_name,....)
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

get

> >the averages ( Master detail related) . It is working very fast but this
> >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
> execution.
>

Sorry I mean TIB_query component. I used two TIB_query components with two
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

are

> in ReadCommitted isolation will see that committed work. Commit makes
> permanent every operation that has been posted since the transaction

began.

>
> Autocommit is a client-side thing, not something the server does. It
> causes a form of commit known as "commit with retain" to follow

immediately

> upon each post. The Commit with Retain (implemented in Delphi by the
> CommitRetaining method) causes a new transaction to start after the

commit,

> without clearing the resources of the preceding transaction. It was put
> 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.
>

Thank You Helen. It is more clear now.


Metin



---
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.
http://www.avast.com