Hi Tim,

I was wondering if there was any reson why you have CachingUpdates as a
private property?

As previously discussed, I've noticed some speed improvements when we turn
on cachingupdates for lookup tables. (So they don't reload data when you get
to the start or end of a table), and I was thinking of making an inherited
DBISamQuery component with CachingUpdates as a public property (so I can
simply set as True in designtime, and forget about it).

Before going down that path, I wanted to check with you to make sure that
this wouldn't cause any complications that you're aware of, but I'm not.

Thanks & Regards

Adam.

Adam,

<< I was wondering if there was any reson why you have CachingUpdates as a
private property? >>

It's public.

<< As previously discussed, I've noticed some speed improvements when we
turn on cachingupdates for lookup tables. (So they don't reload data when
you get to the start or end of a table), and I was thinking of making an
inherited DBISamQuery component with CachingUpdates as a public property (so
I can simply set as True in designtime, and forget about it). >>

CachingUpdates is a "status" property.  What you want to use is
BeginCachedUpdates, etc. for controlling whether they are turned on or not.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> << As previously discussed, I've noticed some speed improvements when we
> turn on cachingupdates for lookup tables. (So they don't reload data when
> you get to the start or end of a table), and I was thinking of making an
> inherited DBISamQuery component with CachingUpdates as a public property
> (so I can simply set as True in designtime, and forget about it). >>
>
> CachingUpdates is a "status" property.  What you want to use is
> BeginCachedUpdates, etc. for controlling whether they are turned on or
> not.

Sorry - what I was meant to ask is is there any reason it's not a published
property, or would changing it to be published cause any problems?

I'm toying with the idea of creating an inherited TDBISamQuery component
where I can set cachingupdates to TRUE in the designer. This way, when the
table first activates (even before the 'onafteropen' event) it will already
be cachingupdates - so VCL components connected to the relevant datasets
won't load before I get a chance to start the cached updates.

These are solely on lookup data (not data that will be edited and then later
posted).

I know I can disable the linked datasource, put some code in on the
onafteropen event, and then reenable the linked datasources, but when you
have over 20 dataset's to work with on each datamodule (and multiple
datamodules), their's a bit of coding involved, and I'd prefer to have it
simple with a property I can set to TRUE or FALSE in the designer.

I don't know if their's any hidden traps in doing this, so I thought i'd ask
first.

Best Regards

Adam.

Adam,

<< Sorry - what I was meant to ask is is there any reason it's not a
published  property, or would changing it to be published cause any
problems? >>

It's a status property, i.e. read-only property.  Hence it wouldn't make any
sense for it to be published.

<< I'm toying with the idea of creating an inherited TDBISamQuery component
where I can set cachingupdates to TRUE in the designer. This way, when the
table first activates (even before the 'onafteropen' event) it will already
be cachingupdates - so VCL components connected to the relevant datasets
won't load before I get a chance to start the cached updates. >>

You can't do that - it's a read-only property.

--
Tim Young
Elevate Software
www.elevatesoft.com