🚀 go-pugleaf

This is a multi-part message in MIME format.
--------------ABE4FD8261D67BE25D787CE8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This may not be very welcome, but would this not be a good candidate for
a TQuery?
Opening it initially should be very quick.

HTH

Howard Lee Harkness wrote:
> I have a TTable which takes several seconds to open (it's huge).
> Meanwhile, the SQL-hourglass cursor comes up, and the application has
> to wait.  Is there a way to start this process, and go do a number of
> other non-database-dependent tasks while the TTable is opening?
> --
> Spam Me and Get Sued <harkness@suespammers.org>
> see www.suespammers.org for details & free spam-nuking email account

--------------ABE4FD8261D67BE25D787CE8
Content-Type: text/x-vcard; charset=us-ascii;
 name="patrickmmartin.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Patrick Martin
Content-Disposition: attachment;
 filename="patrickmmartin.vcf"

begin:vcard 
n:Martin;Patrick
tel;pager:na
tel;cell:07773013982
tel;fax:na
tel;home:01483 303496
tel;work:na
x-mozilla-html:TRUE
url:http://www.freenetpages.co.uk/hp/patrickmmartin/
adr:;;72 Stoke Fields;Guildord;Surrey;;UK
version:2.1
email;internet:patrickmmartin@freenet.co.uk
title:Dr.
note:This is Patrick's home vcard
x-mozilla-cpt:;20176
fn:Patrick Michael Martin
end:vcard

--------------ABE4FD8261D67BE25D787CE8--

Patrick Martin <patrickmmartin@freenet.co.uk> wrote:

>This may not be very welcome, but would this not be a good candidate for
>a TQuery?
>Opening it initially should be very quick.

All suggestions are welcome.  In this case, you got me to re-think my
approach to the problem, and yes, a TQuery was *much* faster, by at
least an order of magnitude.  (Actually, I made some other minor
changes to the design, too)

Thank you.

Spam Me and Get Sued <harkness@suespammers.org>
see www.suespammers.org for details & free spam-nuking email account

There can be other benefits and hinderances of a re-tooling.

E.g. for the Access ODBC driver, I found TTable would often hang
completely getting the fields in a table.
TQuery could do this with a "select * from [Table1]" and was not
noticeably slower with no loss in functionality.


Howard Lee Harkness wrote:
> 
> Patrick Martin <patrickmmartin@freenet.co.uk> wrote:
> 
> >This may not be very welcome, but would this not be a good candidate for
> >a TQuery?
> >Opening it initially should be very quick.
> 
> All suggestions are welcome.  In this case, you got me to re-think my
> approach to the problem, and yes, a TQuery was *much* faster, by at
> least an order of magnitude.  (Actually, I made some other minor
> changes to the design, too)
> 
> Thank you.
> 
> Spam Me and Get Sued <harkness@suespammers.org>
> see www.suespammers.org for details & free spam-nuking email account

patrick martin <patrickmmartin@freenet.co.uk> wrote:

>E.g. for the Access ODBC driver, I found TTable would often hang
>completely getting the fields in a table.
>TQuery could do this with a "select * from [Table1]" and was not
>noticeably slower with no loss in functionality.

I've got a really weird problem with TQuery.  I had a working program
which used TTables, and was a bit slow.  So I put a TQuery in place of
the slowest table.  Sure enough, that sped it up a bunch.

But now the program doesn't work.  I cannot get a DBEdit control to
save it's contents back to the database.  Nor can I get any other
data-aware control to work.  I found and corrected a number of errors,
but I haven't found the magic words.

Yes, I have "RequestLive==true".  I tried putting an implicit
StartTransaction on the opening of the form, and a button to Commit.
No joy.  I thought that a TQuery could be used roughly the same way as
a TTable wrt data-aware components.

Could somebody send me a clue?

Spam Me and Get Sued <harkness@suespammers.org>
see www.suespammers.org for details & free spam-nuking email account

Hi, Howard!

Asking RequestLive does not ensure that you will get the ability to
updat through the query. You may need to use a TUpdateSQL object in
conjunction with it. Check in the
borland.public.cppbuilder.database.sqlservers newsgroup for specific
questions on the use of TUpdateSQL.

------
Mark Cashman (TeamB - C++ Builder), creator of The Temporal Doorway at
http://www.temporaldoorway.com
- Original digital art, writing, music and more -
C++ Builder / JBuilder Tips and The C++ Builder Programmer's Webring
(Join us!)
http://www.temporaldoorway.com/programming/index.htm
------

Mark Cashman <mcashman@temporaldoorway.com> wrote:

>You may need to use a TUpdateSQL object in
>conjunction with it.

Thank-you.  I looked at the documentation on TUpdateSQL, and I was
really dreading it, but it turned out to be fairly easy to implement.
There was even a wizard that populated the SQL statement for me, which
was a very pleasant surprize.

However, it still didn't work, until I turned cached updates on and
did an explicit call to the ApplyUpdates method of the database table
before the Database->Commit().  That was not immediately clear from
the help entry on TUpdateSQL, and I'm a bit uncertain about just what
the ApplyUpdates method does -- the help entry says that it starts a
transaction, but that does not seem to be the case.

I don't know if I have everything arranged optimally yet, but the
world does seem to be round again.

Spam Me and Get Sued <harkness@suespammers.org>
see www.suespammers.org for details & free spam-nuking email account

Hi, Howard!

Make sure you have CachedUpdates = true, and in the AfterPost event do
ApplyUpdates() and CommitUpdates().

I have found that works well. In theory, you only need to call
CommitUpdates() when the program terminates, but if you do things that
way, you need to make sure that it will be called even when there is an
error.

------
Mark Cashman (TeamB - C++ Builder), creator of The Temporal Doorway at
http://www.temporaldoorway.com
- Original digital art, writing, music and more -
C++ Builder / JBuilder Tips and The C++ Builder Programmer's Webring
(Join us!)
http://www.temporaldoorway.com/programming/index.htm
------

Mark Cashman <mcashman@temporaldoorway.com> wrote:

>Make sure you have CachedUpdates = true, and in the AfterPost event do
>ApplyUpdates() and CommitUpdates().

This is a bit unclear.  From the help files, I gather that
ApplyUpdates() writes the cache out to somewhere, and CommitUpdates()
is misnamed, and only clears the cache.

So if I make some changes, call ApplyUpdates(), then CommitUpdates(),
then makes some changes, repeat the ApplyUpdates() and
CommitUpdates(), *then* call the Database->Commit(), will the first
changes get commited to the database?

In the help files, the example shows to ApplyUpdates(), then call the
database Commit(), then CommitUpdates().  Is that sequence actually
required?

TIA for you help.

Spam Me and Get Sued <harkness@suespammers.org>
see www.suespammers.org for details & free spam-nuking email account

Mark Cashman <mcashman@temporaldoorway.com> wrote:

>Make sure you have CachedUpdates = true, and in the AfterPost event do
>ApplyUpdates() and CommitUpdates().

This is a bit unclear.  From the help files, I gather that
ApplyUpdates() writes the cache out to somewhere, and CommitUpdates()
is misnamed, and only clears the cache.

So if I make some changes, call ApplyUpdates(), then CommitUpdates(),
then makes some changes, repeat the ApplyUpdates() and
CommitUpdates(), *then* call the Database->Commit(), will the first
changes get commited to the database?

Also, if I want to cancel the changes to just one TQuery resultset, do
I need to call TQuery::Cancel(), TQuery::CommitUpdates(), or both, or
something else?

In the help files, the example shows to ApplyUpdates(), then call the
database Commit(), then CommitUpdates().  Is that sequence actually
required?

TIA for you help.

Spam Me and Get Sued <harkness@suespammers.org>
see www.suespammers.org for details & free spam-nuking email account

Mark Cashman <mcashman@temporaldoorway.com> wrote:

>Make sure you have CachedUpdates = true, and in the AfterPost event do
>ApplyUpdates() and CommitUpdates().

This is a bit unclear.  From the help files, I gather that
ApplyUpdates() writes the cache out to somewhere, and CommitUpdates()
is misnamed, and only clears the cache.

So if I make some changes, call ApplyUpdates(), then CommitUpdates(),
then makes some changes, repeat the ApplyUpdates() and
CommitUpdates(), *then* call the Database->Commit(), will the first
changes get commited to the database?

Also, if I want to cancel the changes to just one TQuery resultset, do
I need to call TQuery::Cancel(), TQuery::CommitUpdates(), or both, or
something else?

In the help files, the example shows to ApplyUpdates(), then call the
database Commit(), then CommitUpdates().  Is that sequence actually
required?

TIA for you help.

Spam Me and Get Sued <harkness@suespammers.org>
see www.suespammers.org for details & free spam-nuking email account

> >Make sure you have CachedUpdates = true, and in the AfterPost event do
> >ApplyUpdates() and CommitUpdates().
>
> This is a bit unclear.  From the help files, I gather that
> ApplyUpdates() writes the cache out to somewhere, and CommitUpdates()
> is misnamed, and only clears the cache.

Keep in mind that CommitUpdates will actually retry any updates that fail or
were skipped. I never realized this until I actually saw it in action. This
may be ok for some people, but my updates are rely heavily on transactions.
I can't have updates happening behind my back that are outside of
transaction control.

For this reason, I actually call CanceUpdates to clear the cache, even for
successful updates. It's faster, and I don't get the retries. Plus, in my
code I always to a requery after an update anyway. I think if I used
CommitUpdates, I might not have to do a requery (I don't remember).


> So if I make some changes, call ApplyUpdates(), then CommitUpdates(),
> then makes some changes, repeat the ApplyUpdates() and
> CommitUpdates(), *then* call the Database->Commit(), will the first
> changes get commited to the database?

I believe so.

> Also, if I want to cancel the changes to just one TQuery resultset, do
> I need to call TQuery::Cancel(), TQuery::CommitUpdates(), or both, or
> something else?

Cancel only makes sense when a dataset is in insert or edit mode. The cancel
operation takes the dataset back to browse mode, and aborts changes to that
one record. If this is what you want, use Cancel. If you want to completely
wipe all pending changes to all records in a datatset, call CancelUpdates.
CommitUpdates may actually do something you don't want.

PS: CommitUpdates and CancelUpdates only make sense in datasets that use
CachedUpdates. Cancel is a routine that you can always use.

> In the help files, the example shows to ApplyUpdates(), then call the
> database Commit(), then CommitUpdates().  Is that sequence actually
> required?

It's not the required sequence, but I think it is the sequence that makes
the most sense.

--
Harold Howe [TeamB]
BCB tips and articles:        http://www.bcbdev.com
Custom software development:  http://www.bcbdev.com/resume.htm

On Thu, 06 Sep 2001 13:21:54 -0500, Mark Cashman
<mcashman@temporaldoorway.com> wrote:
>
>>Make sure you have CachedUpdates = true, and in the AfterPost event do
>>ApplyUpdates() and CommitUpdates().

I wrote:
>> In the help files, the example shows to ApplyUpdates(), then call the
>> database Commit(), then CommitUpdates().  Is that sequence actually
>> required?

 Harold Howe \(TeamB\) (hhowe@bcbdev.com) replied:
>It's not the required sequence, but I think it is the sequence that makes
>the most sense.

For some reason, my newsreader did not pick up Harold's reply, so I
didn't see it until I did a search on Google.

I have been experimenting with this, and I am puzzled.  Does the
ApplyUpdates() take the place of a Post()?  When I tried doing both,
the Post() gave me an error.  What exactly does Post() do for a
TQuery?

Spam Me and Get Sued <harkness@suespammers.org>
see www.suespammers.org for details & free spam-nuking email account