Hi Tim,

Found an interesting one today I was hoping you could help with. I have the
following code. (Admitidally the LOG table is rather large), however things
run quite fast until we hit the close command for the table. (Just to make
sure the table wasn't doing anything else, I've tried putting in a .open and
..close again, and trapped the 2nd close, which also takes about a second to
accomplish).

The code I'm using is as follows:

LogT.disablecontrols;
LogT.Open;
LogT.Insert;
LogTDateTime.value         := now;
LogTUser.value             := _Username;
LogT.Post;
LogT.Close;      //Why does it run slow here?!!?
LogT.open;
LogT.close;        // It also runs slow here (nearly a second to
accomplish)
LogT.enablecontrols;

The table in question is a local table (ie, not using the DBISam C/S setup).

Are you able to shed some light on this?

Thanks & Regards

Adam.

Adam,

<< Found an interesting one today I was hoping you could help with. I have
the following code. (Admitidally the LOG table is rather large), however
things run quite fast until we hit the close command for the table. (Just to
make sure the table wasn't doing anything else, I've tried putting in a
..open and .close again, and trapped the 2nd close, which also takes about a
second to accomplish). >>

The first place to look is always any table events attached to the
TDBISAMTable component.   After that, the rest is probably down to the OS
trying to flush buffers during the close, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Thanks for your reply...

> The first place to look is always any table events attached to the
> TDBISAMTable component.   After that, the rest is probably down to the OS
> trying to flush buffers during the close, etc.

No events on the dataset. Guess it must be the OS flushing buffers. Will try
changing the script to SQL to see if this will make things run any faster.

Best Regards

Adam.

Adam,

<< No events on the dataset. Guess it must be the OS flushing buffers. Will
try changing the script to SQL to see if this will make things run any
faster. >>

How about lookup fields, calculated fields, etc. ?  Also, you might want to
rule out an external cause like AV software, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Thanks for the reply.

> How about lookup fields, calculated fields, etc. ?  Also, you might want
> to rule out an external cause like AV software, etc.

No on all accounts (except I didn't test for AV and will do).

As for converting to SQL, it didn't speed up as fast as I thought it might.
Maybe I'm expecting too much speed out of a 30mb table.

Cheers

Adam.

Adam,

<< As for converting to SQL, it didn't speed up as fast as I thought it
might. Maybe I'm expecting too much speed out of a 30mb table. >>

A 30MB table is small.  These newsgroups that you're posting on include a
872MB article.blb, a 157MB article.idx, and a 118MB article.dat, and they
must be opened and closed for every single NNTP operation in addition to
every web request via our web-based newsgroups.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:630C130C-413A-47B6-9970-A14F7CD696EB@news.elevatesoft.com...
> Adam,
>
> << As for converting to SQL, it didn't speed up as fast as I thought it
> might. Maybe I'm expecting too much speed out of a 30mb table. >>
>
> A 30MB table is small.  These newsgroups that you're posting on include a
> 872MB article.blb, a 157MB article.idx, and a 118MB article.dat, and they
> must be opened and closed for every single NNTP operation in addition to
> every web request via our web-based newsgroups.
>

I use tables much larger than that, and they open and close almost instanty.
You have something there - a control requesting tons of dta, a lookup, an
event handler, something - that is causing the problem.

Robert

Hi Tim and Robert,

Sorry for the delayed reply - chaotic is the best description for my work
load at the moment...

>> A 30MB table is small.  These newsgroups that you're posting on include a
>> 872MB article.blb, a 157MB article.idx, and a 118MB article.dat, and they
>> must be opened and closed for every single NNTP operation in addition to
>> every web request via our web-based newsgroups.
>
> I use tables much larger than that, and they open and close almost
> instanty. You have something there - a control requesting tons of dta, a
> lookup, an event handler, something - that is causing the problem.

The dataset was there by itself, no lookups, no event handlers, zippo.

However, I haven't had a chance to see yet if there's another
program/service that's causing the problem, and I'm becomming suspicious
that this may be the case.

Thanks for your help!

Adam.

Adam,

<< However, I haven't had a chance to see yet if there's another
program/service that's causing the problem, and I'm becomming suspicious
that this may be the case. >>

If it's not internal to your application, then it is almost always down to
some external software mucking around with the file I/O.

--
Tim Young
Elevate Software
www.elevatesoft.com