I have a table with a two field, descending index on the fields
AcctNum and EndTime.  Setting the IndexFieldNames property at runtime
to "AcctNum;EndTime" produces the error 'No index for fields
'AcctNum;EndTime'.  Selecting the index in DBSYS works fine and orders
the table correctly.  It wasn't working in v4.21 so I upgraded to
v4.22b4 but get the same results.

Any ideas?
Al

Al,

If you are using persistent fields, make sure both of those
fields are included in the fields defined in the field
editor. Also, try changing the index using the index name to
see if there is maybe some other underlying error.

Sean

alanc@jancointernational.com (Al Craker) wrote:

> I have a table with a two field, descending index on the fields
> AcctNum and EndTime.  Setting the IndexFieldNames property at runtime
> to "AcctNum;EndTime" produces the error 'No index for fields
> 'AcctNum;EndTime'.  Selecting the index in DBSYS works fine and orders
> the table correctly.  It wasn't working in v4.21 so I upgraded to
> v4.22b4 but get the same results.
>
> Any ideas?
> Al

Both fields are included in the persistent fields.  I actually have 4
indexes defined, one is just an autoinc field, the other three are all
decending indexes.

Even in design mode, selecting the dropdown on the IndexName property
lists all four indexes.  Selecting the dropdown on IndexFieldNames
doesn't list any of the decending indexes.

Al,

<< I have a table with a two field, descending index on the fields AcctNum
and EndTime.  Setting the IndexFieldNames property at runtime to
"AcctNum;EndTime" produces the error 'No index for fields 'AcctNum;EndTime'.
Selecting the index in DBSYS works fine and orders the table correctly.  It
wasn't working in v4.21 so I upgraded to v4.22b4 but get the same results.
>>

It's a limitation in the way the IndexFieldNames works - it doesn't accept
descending indexes.  This is basically a carry-over from the BDE
compatibility.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:EED03519-EA50-4888-9182-898C5B688CA6@news.elevatesoft.com...
> Al,
>
> << I have a table with a two field, descending index on the fields AcctNum and EndTime.  Setting the IndexFieldNames property at
> runtime to "AcctNum;EndTime" produces the error 'No index for fields 'AcctNum;EndTime'. Selecting the index in DBSYS works fine
> and orders the table correctly.  It wasn't working in v4.21 so I upgraded to v4.22b4 but get the same results.
> >>
>
> It's a limitation in the way the IndexFieldNames works - it doesn't accept descending indexes.  This is basically a carry-over
> from the BDE compatibility.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

basically there is no such thing as a descending index.
you either read it forwards or backwards
if you need to go backwards simply set the index then go bottom and goprev
or SQL wise use Order by Desc and go next

gregF

Greg,

<< basically there is no such thing as a descending index. >>

In DBISAM there is.  It is hard-coded because individual columns in the
index can be descending as opposed to the entire index.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:6A333CB6-1639-4CB2-84EB-EFCC4490D0F7@news.elevatesoft.com...
> Greg,
>
> << basically there is no such thing as a descending index. >>
>
> In DBISAM there is.  It is hard-coded because individual columns in the index can be descending as opposed to the entire index.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

I was alluding to the fact that a descending index
is in fact a processing attribute but the value
of the DBMS to support it is to save a temp index
IE why is any part of an index descending, because an application
decision has been made to handle a particular
processing decision thus this can be handled
programmatically and the DBMS doesn't really need to
but for expediency we have that facility

(IE Cust_Id , Desc Order_Date) as we usually like to
see the last order first for any customer

gregF

Greg,

<< I was alluding to the fact that a descending index is in fact a
processing attribute but the value of the DBMS to support it is to save a
temp index IE why is any part of an index descending, because an application
decision has been made to handle a particular processing decision thus this
can be handled programmatically and the DBMS doesn't really need to but for
expediency we have that facility >>

I understand.  I was simply pointing out that it's a little more complicated
when the direction is not necessarily asc/desc for the entire index key.

--
Tim Young
Elevate Software
www.elevatesoft.com