![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 8 of 8 total |
![]() |
Wed, Jan 25 2006 11:34 AM | Permanent Link |
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 | |
Wed, Jan 25 2006 1:58 PM | Permanent Link |
Sean McCall | 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 |
Wed, Jan 25 2006 2:50 PM | Permanent Link |
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. | |
Wed, Jan 25 2006 6:57 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
Thu, Jan 26 2006 4:44 AM | Permanent Link |
"GregF" | "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 |
Thu, Jan 26 2006 8:45 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
Fri, Jan 27 2006 1:44 AM | Permanent Link |
"GregF" | "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 |
Fri, Jan 27 2006 9:38 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |