Thanks for a prompt reply Geoff.
Yes I am always re-inventing the wheel.

Option 1. Rewrite it all ...yes in the long term.
I do use transactions a lot. But there is a delay of about 20 mins while the
customer cogitates (or even half a day sometimes ) and I don't like to hold
a transaction that long. So I hold everything in standard delphi objects.

I dont understand 'cached updates' yet.

Option2.
Yes this is what I have done. But I have changed a lot of the tables about.
And this means altering the stored procs which feed them. So my mind was
directed towards giving up stored procs and using the flexibilty and
convenience of tib_query.

I have worked out that I am daft to create all my queries as I need them.
Much better to put the appropriate ones on a datamodule and create that when
needed...that way I can play with the visual queries in design mode.

I think I am nearly there:
I Create the data module. with query on it.
I have set up the 'UpdateSql' business on the visual query.
and set requestlive to true.
Then I say

step 1 "qryAddress.sql := qryAddress.InsertSql" ... ???
step 2. "qryAddress.prepare"
step 3 "parambyname('postcode').asstring := theaddress.postcode;
and so for all the params
step 4. "qryAddress.insert;

Is This near ?


""Geoff Worboys"" <geoff@...> wrote in message
news:013d01c13dcb$68057c90$0201950a@hex...

> > For example I have a collection of TAddress objects
> > some of which are Tnewaddress objects and some are
> > ToldAddress objects.
>
> It sounds like you have built yourself some sort of cached update
> arrangement. That you are not using data-aware controls, but rather
> you are feeding thise Tnew* and Told* objects from "standard"
> controls. Given this I imagine that you have a form of controls which
> feed these objects and then when the user hits the "Save" button you
> process the objects to the server.
>
> Am I close to correct?
>
>
> If I am correct then I think you have two options...
>
> 1. Discard all your previous work and rewrite using IBO-aware controls
> and TIB_Query components. You can still "batch" your work either
> using cached updates (built into IBO) or using transactions - which
> are designed for specifically this purpose.
>
> OR
>
> 2. Ignore most of IBO and simply use the TIB_Cursor and/or TIB_DSQL
> components with parameters (to provide the key information for
> locating the records to be updated, deleted). If using TIB_Cursor you
> simply call Insert or Edit and then update the fields
> (IB_Cursor1.FieldByName(...)) as required and then call Post.
>
>
> There is probably little point in going into more detail until we know
> whether my above assumptions are correct, and which path you wish to
> follow.
>
> I will say that option 2 will leave you with much more code to write,
> and will not take advantage of many of IBOs built-in capabilities.
> However it would allow you to keep much more of your current
> application. Note that TIB_Query is really setup for user
> interaction using IBO-aware controls, more often than not it is
> inappropriate in other circumstances.
>
>
> Geoff Worboys
> Telesis Computing
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>