In looking at a plan I note that it says:
"Result set will be ordered by the following column(s) using a case-
sensitive temporary index:"

I thought I'd set an index, and indeed I had. It is an integer field, and
the index I created is case insensitive as it didn't seem relevant.
Obviously DBISAM isn't going to use it as numbers are case sensitive. Is
there anything more behind this? Surely the integer index is usable both
ways?

/Matthew Jones/

Matthew,

<< I thought I'd set an index, and indeed I had. It is an integer field, and
the index I created is case insensitive as it didn't seem relevant.
Obviously DBISAM isn't going to use it as numbers are case sensitive. Is
there anything more behind this? Surely the integer index is usable both
ways? >>

Yes, it is usable both ways, and the same type of query here seems to work
fine with 4.24 Build 1:

================================================================================
SQL statement (Executed with 4.24 Build 1)
================================================================================

SELECT * FROM customer ORDER BY Custno

Tables Involved
---------------

customer (customer) table opened shared, has 55 rows

Result Set Generation
---------------------

Result set will be live

Result set will consist of one or more rows

Result set will be ordered by the primary index for the table customer

================================================================================
>>>>> 55 rows affected in 0 seconds
================================================================================

The primary index of the customer table is a case-insensitive index on the
CustNo float field.

--
Tim Young
Elevate Software
www.elevatesoft.com

Okay, I'll check my observations then. Including that there was an index
on the field in question. For now I've removed that option for each
numeric field anyway.

/Matthew Jones/