Should SEEK change ORDER permanently?

[Toman]

Nice day to all.

I've noticed (using VFP7) that issuing command SEEK with phrase DESCENDING changes order of appropriate TAG in a table even after SEEK is done. It seems to be a little insidious.

According to helpfile DESCENDING in SEEK specifies that the table is searched in descending order. Nothing about a leaving table with order changed.

Need to say that after closing and reopening the table is the ORDER as it was in the beginning (before a SEEK).

Could someone more experienced tell a word on that.

Thank you
Tom

 

[Mike Lewis]

Tom,

This is not what I'm seeing.

Can you post an exact sequence of commands that will produce this behaviour.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Toman]

Mike, thank you for trying to help me. Tom

* make a table tmp for demonstration
	Create table tmp (id n(2),name c(20))
	Insert Into tmp (id, name) Values (3, "Mike")
	Insert Into tmp (id, name) Values (9, "Paul")
	Insert Into tmp (id, name) Values (2, "John")
	Insert Into tmp (id, name) Values (1, "Ringo")
	Insert Into tmp (id, name) Values (5, "Georges")
	Insert Into tmp (id, name) Values (7, "Worcester")
	Insert Into tmp (id, name) Values (6, "Abbey")
	
* add some index (ASCENDING)
	INDEX ON id TAG id 

* check whether order for the TAG id is really ascending
	SET ORDER TO id
	? DESCENDING()	&& .F. -> yes, ascending of course

* no controlling index needed
	SET ORDER TO

* now searching for a record with id = 5
	SEEK 5 ORDER id DESCENDING IN tmp	&& there's no reason to use DESCENDING here, but sometimes there is

* a record found, let's have a look
	? id, name

* and now, what about order for the TAG id - is still ascending?
	SET ORDER TO id
	? DESCENDING()	&& .T. -> no, descending, sorry

* Sooner or later a problem might occur,
* TAG id in tmp table was created with ASCENDING ORDER and without visible touching them
* it is now DESCENDING

* The solution is simple, just to know that any solution is needed

 

[Mike Lewis]

Tom,

Very interesting.

In VFP 8.0 and 9.0, I don't see the same behaviour. The index remains ascending (the last executable command prints .F.).

But in VFP 7.0, I see what you are seeing. That suggests it was a bug that has been fixed. I don't recall ever seeing this documented.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Toman]

Another reason why always upgrade VFP as high as possible.

Maybe also a tip for other programmers using VFP 7.0 or less: check your older projects for occurrence of keywords SEEK and DESCENDING.

Thank you, Mike.
Tom

 

[Mike Lewis]

Tom,

Presumably, you could put it right by issuing SET ORDER ... ASCENDING after the SEEK - provided you know to do it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Imaginecorp]

Tom its not a bug...Its your code. Of course it will be descending, lets look at what you are doing:

you have a created an index - default is Asc
INDEX ON id TAG id
SET ORDER TO id
? DESCENDING() && .F.

*** here is the kicker: you release the index
SET ORDER TO
*** now you call the index and change the index order
SEEK 5 ORDER id DESCENDING IN tmp

*** You have not changed the order, but are just calling the same index
SET ORDER TO id

DESCENDING() && .T. -> no, descending, sorry
*** Naturally, you are refrencing the same index whose order you changed in code.

If you change:
SET ORDER TO id
to
SET ORDER TO
then acll it, It will revert back to Ascending

 

[Mike Lewis]

Imaginecorp,

its not a bug...Its your code.

If that's so, I wonder why they changed the behaviour between 7.0 and 8.0.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Toman]

Imaginecorp,

I agree with you in that way, that programmer is always responsible, bugs or no bugs, but I don't understand well the rest.

You say: You changed the index order by calling SEEK command.
I say: SEEK changes order of appropriate TAG in a table
It is the same.

The only difference is in our assumption whether command SEEK is capable to change the order permanently or not. I take the assistance from Microsoft VFP help file to my opinion.

Everyone who wants to bring more light into this thread should explain, why SEEK should change the order permanently, eventually which authority has stated that. According to Mike, SEEK does not change the order in VFP 8.0 and 9.0 and it seems normal and useful to me.

Thank you, Tom.

 

[Dan Freeman]

Guys, have you actually browsed the data when descending() is returning .t.?

It was broken for many years and didn't always tell the truth.

 

[Imaginecorp]

Well;
"its not a bug...Its your code." was a little strong.

Tom:
The seek did not change the index permanently. Your code changed the "Opened" (Attached) index order. Forget the SEEK, you would have the same problem with Set Order To id Desc.
Think about it... You created the index (default Ascending)But did not attach it to the table. So its just an index sitting out there.
With the SEEK you attached it to the table but made it Descending.
Now you attached the same (Descending) index with the Set Order to id
Now if you were to "close" the index with a SET ORDER TO and now do a Seek, it will be in its original created stage (Ascending) try it...
Unfortunately, I do not have VFP7 on my machine so cannot test...

 

[Mike Lewis]

Dan,

Guys, have you actually browsed the data when descending() is returning .t.?

Yes. I did that with the tests I described above. In 7.0, the Browse showed the records in descending order. In 8.0 and 9.0 they were ascending.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

AFAIR the permanent order change was by design and it seems they changed it due to problems given by using the same table again and/or in different sessions.

The permanent change was also the case using SET ORDER TO TAG tagname DESCENDING. And could be fixed by SET ORDER TO TAG tagname ASCENDING. So the rule is simply to never trust the index is in some "natural" order, like the way when you created the index. Instead you should always tell VFP what order you need the index in.

But due to the AGAIN or sessions making problems theay may have changed the design. You might try what happens in VFP7 if you use the same index on two different datasessions:

Create table tmp (id n(2),name c(20))
Insert Into tmp (id, name) Values (9, "Paul")
Insert Into tmp (id, name) Values (2, "John")
Insert Into tmp (id, name) Values (1, "Ringo")
Insert Into tmp (id, name) Values (5, "George")
index on id tag xid ascending
use

public s2,s3
s2 = createobject("session")
s3 = createobject("session")

set datasession to s2.datasessionid
use tmp in 0 order tag xid ascending

set datasession to s3.datasessionid
use tmp in 0 order tag xid ascending
use tmp in 0 again alias tmp2 order tag xid descending

set

Now change to Session(2), browse, change to Session(3) and browse both tmp and tmp2, see if records are ordered as displayed with the up/down array in the datasession window.

In VFP9 this works as it should, in Session(2) records are ordered ascending, in Session(3) ordered both ways in tmp and tmp2, no side effects.

Bye, Olaf.