Hi Ralf,

Thanks for your suggestion. I tried that, and it executes in around 8
seconds.

Are you thinking that having the where clause on a joined table instead
of the primary may be the issue?

> Select distinct AC.ID
>  From ApprenticeVisits AV
> left outer join ApprenticeCourse AC on (AV.AppCourseID = AC.ID)
> where (AV.VisitType = 'PC')

Cheers

Adam

Hi Raul,

Yeah - I'm thinking that might be the way to go, although I know Tim is
AWOL for a few days over Christmas, so I wont worry about bothering him
until he's back and has a clear mind, fully recovered from the Christmas
Spirit (or whatever alcoholic beverage he might be drinking)

Cheers for your help guys. Have a safe Christmas...

Adam.


On 21/12/2012 4:04 PM, Raul wrote:
> Ada,
>
> It's probably worthwhile to email elevate support (Tim) direct with this
> - he'd be able to provide a definitive answer on what can be done.
>
> Raul
>
>
>
> On 12/20/2012 7:56 PM, Adam H. wrote:
>> Hi Raul,
>>
>> It's really got me beat at the moment. Two different machines (OS's)
>>
>> I'm suspicious that it's the join that's causing issues, and not the
>> actual where clause, as it runs slow even without the where in there
>>
>> Cheers
>>
>> Adam.
>

Adam,

Per email:

Yes, this is down to Windows caching.  DBISAM relies on the Windows file
system to do the bulk of the caching in order to improve file access times.
The DBISAM buffering is minimal and only comprises a few hundred KB, at
most, by default.  Unfortunately, there's really no way around this.

Tim Young
Elevate Software
www.elevatesoft.com