I have run tests on my UniData 6.0.9 system on Solaris 2.8. I was testing what affected the sort order of SELECT JOB WITH CONO = "001" from an ascending ID sort before re-indexing (with an additional field) to a descending ID sort after.
I tested every combination of the selected field having a format of "3L" or "3R", of being defined as single (S) or multi (M) (not MV!) valued, the presence of a long field called DESC or JOB_DESC or not being included, and setting the alternate key length to 8 or 20. The only investigated factor that changed the sort order of the select list was whether the field CONO, which is a virtual attribute that is part of the key, was defined as single valued "S" or multi-valued "M" in field 6 of the dictionary. When CONO was single valued the SELECT provided an ascending key sort and when CONO was multi-valued the SELECT provided a descending key sort. I thought that the field had always been defined with "M" in field 6 as a result of an automated conversion from Pick days to UniData and it certainly provided an ascending sort until I deleted and recreated the indices. Who knows? Karjala >>> [EMAIL PROTECTED] 10/06/2004 5:18:31 PM >>> Oops! ... I will make a more rigorous round of tests tomorrow to try to pin down the change because I cannot yet replicate the changes I observed. The tests will include the presence and absence of the DESC field, and if that makes a difference in a non-SQL environment, adding it with a different name. Karjala ... -----Original Message----- From: Karjala Koponen [mailto:[EMAIL PROTECTED] ... I recently added an additional alternate index to one of my files. ... The sort order of SELECT JOB WITH CONO = "001" changed from an ascending ID sort before the re-indexing to a descending ID sort after. I did the same things on UniData 5.2 on AIX and UniData 6.0.9 on Solaris 2.8 with the same results. ... Karjala ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
