I must be dense in my old age (?!!) but would this not
be gotten around if the new posted event is _outside_
of _any _ user's transactions. I forsee that it would
be as if the database itself was a user and posted a
change to the given DML process, therefore updating
the triggers, and letting all users, using the given
record, would show a trigger update?

(A procedure IN the database that posts a DML record
with a dummy user DMLID and then a triggered event in
the DML that send to the caller of the procedure)

( Sorry I get too wordy at times :} )

Steve Fields

Helen Borrie wrote:

>
> At 10:10 AM 27-09-02 -0500, you wrote:
> >What if.....
> >1. I create a generic user that no one has ready access to.
> >2. In the database I give this user all access to _DML_ tables.
> >3. In the database I create a procedure that posts a update
> > record in DML$IBOCACHE (much like the DML$IBOCACHE trigger)
> >4. I can then call this procedure from any app.
> >
> >Then this will, in effect, simulate another user updating the
> >current _live_ record that the user is working with. ????
> >
> >Steve Fields
>
> Erm...no.
> In documentation we loosely use the term "user" when we mean "connection"
> and, sometimes, "transaction" (or both). A user is only meaningful in
> terms of a connection - so to do any work, your phantom user would (a) have
> to be connected and b) have some way to know that an application wanted it
> to update something. In a sense, DMLCaching gives you what you describe,
> without a "different" user being involved, since it involves database events.
>
> >I was under the impression that to commit it
> > > would close the datasets relating to the database and
> > > would therefore _lose_ the record I was letting the user
> > > view.
>
> No. You have RefreshAction and CommitAction to control the position of the
> cursor after closing and reopening datasets, and after committing work,
> respectively.
>
> > > This is for a basic invoice/lineitem type of system,
> > > with twists relevant to our situation. I would make the
> > > changes in the background to the line items and the base
> > > totals, etc with a tib_cursor or a tib_dsql, (whatever it
> > > takes) but needed the values to update immediately on posting
> > > the lineitem changes. I am using all of the DML settings as
> > > true for each dataset involved (TIB_Queries and a few
> > > tib_cursors).
>
> I've kinda lost the original description but I get the impression you are
> making a self-perpetuating problem for yourself, by denying the dataset its
> native behaviour of updating itself.
>
> Basically, inserting, deleting and editing the current row are "things that
> a dataset knows how to do" in our OO model. IBO hides the whole process of
> the dataset constructing the SQL required for it to achieve these DML
> operations.
>
> With a plain-jane dataset, there is virtually nothing for you as the
> programmer to do except to ensure that the dataset knows how to locate the
> underlying row in the dataset (by supplying KeyLinks) and selecting the
> BufferSynchroFlags to set up how the dataset should respond to
> changes. With a more complex dataset, such as one involving joins, you
> help the dataset to achieve the DML operations by supplying custom SQL in
> the InsertSQL, EditSQL and DeleteSQL properties.
>
> Whether your dataset uses the default SQL statements or custom ones you
> have supplied in the xxxxSQL properties, refreshing the dataset after a
> commit is sufficient to give your application the updated view of the
> database state. An appropriate combination of BufferSynchroFlags,
> RefreshAction and CommitAction will allow you to set up the exact behaviour
> you want.
>
> What DML caching does is to add another level of synchronisation (or three
> more levels, to be more exact). It makes your datasets aware of changes
> committed by other transactions immediately those commits occur, rather
> than waiting until next time the dataset's work is committed. If you don't
> code in what you want the dataset to do in response to a DMLCache message
> (using the OnDMLCacheAnnounceItem and OnDMLCacheReceiveItem events) the
> behaviour with DMLCaching will be no different to the standard behaviour of
> IBO datasets...
>
> Helen
>
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/