|
Home > Archive > FoxPro Help and Support > July 2005 > VFP6 / VFP8 and SET ORDER TO
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
VFP6 / VFP8 and SET ORDER TO
|
|
| Villi Bernaroli 2005-07-27, 11:38 am |
| A lot of code here at my studio is relaying on the way VFP6
handled the DESCENDING() status of the tables when you issue a
SET ORDER TO, which in VFP8 has changed.
In VFP6 we used to do:
select mytable
set order to 1 descending
* ... much code between
set order to 1
and the table would still be in a descending status.
In VFP8, the same sequence of commands brings to a table in
ascending order, since in VFP8 the command "set order to nTag"
behaves as "set order to nTag ascending" used to do in VFP6: it
forces ascending ordering.
So, now that we moved to VFP8, much of the code here is behaving
differently from before, since descending-ordered tables lose the
descending() status when we issue a "set order to nTag" without
specifying ASCENDING or DESCENDING.
Is there a SET ... who can restore the old (VFP6) behavior of the
"SET ORDER TO nTag" command? Or do we have to manually modify our
code (and code generation routines)?
--
The answer to the ethernal question is:
put a read events after the launch of the form
| |
| Dan Freeman 2005-07-27, 11:38 am |
| I'm afraid you're out of luck. FWIW, some of us thought the previous
behavior was a bug and started explicitly putting ASCENDING or DESCENDING on
*every* set order statement. <shrug>
Dan
Villi Bernaroli wrote:
> A lot of code here at my studio is relaying on the way VFP6
> handled the DESCENDING() status of the tables when you issue a
> SET ORDER TO, which in VFP8 has changed.
> In VFP6 we used to do:
>
> select mytable
> set order to 1 descending
> * ... much code between
> set order to 1
>
> and the table would still be in a descending status.
> In VFP8, the same sequence of commands brings to a table in
> ascending order, since in VFP8 the command "set order to nTag"
> behaves as "set order to nTag ascending" used to do in VFP6: it
> forces ascending ordering.
>
> So, now that we moved to VFP8, much of the code here is behaving
> differently from before, since descending-ordered tables lose the
> descending() status when we issue a "set order to nTag" without
> specifying ASCENDING or DESCENDING.
> Is there a SET ... who can restore the old (VFP6) behavior of the
> "SET ORDER TO nTag" command? Or do we have to manually modify our
> code (and code generation routines)?
|
|
|
|
|