Hi.

I was using in my software index "Case-insensitive" and i have changed to
"Case-sensitive", from this moment the application works very very very very slowly.

It's possible?

Thank you

Francisco


I seem to remember something about this in earlier posts and I'll see if I can find it.

Can you expand a bit more on "the application works very very very very slowly", is this lookups, populating dbgrids, running queries or .....? Also can you give an idea of how much slower it is? Finally which version of ElevateDB?

Roy Lambert [Team Elevate]

Roy

I'm migrating my bde application to ElevateDB and i'm working with 2.0.

I use a unit to manage tables that add, find and replace records in the tables.

First i was using tables with "Case-insensitive" index and my application works fine.
Later i change the index to "Case-sensitive" and it's five times slowly than when i use
index "Case-insensitive" when i add, find or replace records.

Thank you

I forget it.

I'm using TEDBTable component.

Francisco


Can't find the post I though was there. I presume the situation you have is something like:

column ANSI

index ANSI_CI

procedure
if Locate('fld',data,[loCaseInsensitive]) then begin
alter some value
post
end;
end;

or are you using FindKey?

Local, network or c/s?

Let me know and I'll try it here.

Roy Lambert [Team Elevate]

Roy

Let me comprobe a few things and i tell to you.

Thank you very much

Francisco,

<< I was using in my software index "Case-insensitive" and i have changed to
"Case-sensitive", from this moment the application works very very very very
slowly. >>

If you're using Lookups, Locates, and Filters, then such a change would
automatically change optimized searches and filters to un-optimized filters
and searches.  See here for more information on collations:

http://www.elevatesoft.com/articles?action=view&articleno=2

--
Tim Young
Elevate Software
www.elevatesoft.com

Ok

Thank you all

Tim

><< I was using in my software index "Case-insensitive" and i have changed to
>"Case-sensitive", from this moment the application works very very very very
>slowly. >>
>
>If you're using Lookups, Locates, and Filters, then such a change would
>automatically change optimized searches and filters to un-optimized filters
>and searches. See here for more information on collations:

Not sure I understand this. Is it because the data is ANSI_CI and the index is ANSI or ....?

I can see and understand the sql side of collations but I thought that ElevateDB would use the available index regardless of case sensitivity for tables.

Roy Lambert [Team Elevate]

Roy,

<< Not sure I understand this. Is it because the data is ANSI_CI and the
index is ANSI or ....? >>

If he changed the index and things started going slower, than it's pretty
logical that the searches, etc. are not using available indexes.  With
Locates, for example, you have to specify the loCaseInsensitive switch to
match a case-insensitive index.

<< I can see and understand the sql side of collations but I thought that
ElevateDB would use the available index regardless of case sensitivity for
tables. >>

Not for Locates, no.  And lookups use Locates also.

--
Tim Young
Elevate Software
www.elevatesoft.com