I would be interested but my _company_ just purchased the
full package of IBObjects, Delphi 5 Enterprise etc. and
they do not look lightly on any expenditures. Unless they
are free..... :\ That is why I spend so much time in this
newsgroup trying to get around or make what I have work
the way (unsual ways) they want it....

Thanks anyway,
Steve Fields

Thomas Steinmaurer wrote:

>
> Hi Steve,
>
> I haven't followed the complete thread, but this might be worth
> a reading too.
> http://www.iblogmanager.com/dmlcaching/about_ibo_dml_caching.html
>
> It shows, how IB LogManager 2.1 can act as integrator for the
> Global DML Caching mechanism of IB Objects.
>
> Regards,
> Thomas Steinmaurer
> IB LogManager 2.1 - The Logging/Auditing Tool for InterBase and Firebird
> http://www.iblogmanager.com
>
> > -----Original Message-----
> > From: news@... [mailto:news@...]On Behalf Of Steve
> > Fields
> > Sent: Friday, September 27, 2002 7:54 PM
> > To: IBObjects@yahoogroups.com
> > Subject: Re: [IBO] DML updating using tib_cursor
> >
> >
> > Ok, here is what I was doing and here is the result:
> > In an app I would have a master detail record with a grid
> > below it. On the base record I would change a field that
> > was reflected in the detail records, vendor id for example
> > changed. The vendor id was not a indexed field for other
> > reasons. When it changes, however, I would need to change
> > it in each of the related details. If I left the detail
> > dataset linked (not using disablecontrols) I would get
> > a lot of scrolling in the grid of items as I stepped through
> > thej details, changing the field. To get around this
> > I would use a tib_cursor to make the change in the
> > background. Doing this, however, (again) would not reflect
> > in the grid. To try to make the changes visible I tried
> > to refresh the master record: no change. Tried to refresh
> > the detail tib_query, still no change. If there is a simple
> > fix to this I am all for it, I just havent found it yet
> > and I have tried quite a few work-arounds on this....
> > (BTW I am using DML cacheing with a primary key in both
> > detail and master using defind mastersource and masterlink)
> >
> > Thanks,
> > Steve Fields
> >
> > Helen Borrie wrote:
> > > 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/
> >
> >
> >
>
>
> ___________________________________________________________________________
> 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/