BROWSE ... NOFOLLOW

[Mike Lewis]

Over in thread184-1813091, I mentioned that I thought the BROWSE command had an optional NOFOLLOW clause. But I couldn't find any mention of it in the Help or anywhere else. I remembered the clause from dBASE (or it might have been Foxbase), but I wasn't sure of the details.

As far as I remember, it worked like this: If you BROWSE an indexed table, and insert a record into it, the record will normally appear in the correct place in index order. But if you BROWSE NOFOLLOW the table, the record appears at the end of the table, regardless of its position in the index. (Of course, the record is always physically inserted at the end of the table; I'm just talking here of what appears in the Browse window.)

I think a similar behaviour occurs if you update the indexed field in an existing record.

I've just been doing some testing, but I can't see a consistent behaviour. The NOFOLLOW keyword appears still to be in the language, given that it does not produce an error, but Intellisense does not auto-complete it. But I haven't been able to confirm exactly what it does.

Does anyone have any information about this? I'm only asking out of curiosity. It's not something I am likely ever to use.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Trento777]

Hi, Mike.

This might help (in french):

http://dbase.free.fr/documentation/instructions/dbase browse.htm

Best regards.


Eric J. Muñoz H.
GDL, MX.

 

[Chris Miller]

I just checked a usual browse without NOFOLLOW and even then new records don't sort into already existing rows.
I see NOFOLLOW is listed in reserved words, but nowhere else.

Anyway, now I think this is only a feature of Browse and not the grid. The grid must have AllowAddNew=.T. and then you don't add records with CTRL+Y but by down arrow when you're in the last record.
And then the new record also isn't sorted in unless you refresh the grid, also when you move within the grid. And that has a strange side effect, when the new record isn't the last by index sort order, that means using down arrow puts you up in the grid to the row with the next higher value and even when you go down from the last record in index order that doesn't hit EOF and no new record is created.

Instead you end up in your last new record that's still in the end and you just cycle to some records with the down arrow without ever adding a new record.

That's surely also a problem but not the one reported. So that must involve some code, maybe a grid refresh.

This makes me wonder whether that was a bug of the grid since AllowAddNew was introduced. I remember CTRL+Y also worked in the grid, but now doesn't anymore.

Chriss

 

[Steve Meyerson]

Just for kix, I dug into my archived folders from xxx years ago.

This is a Notepad extract from file FoxHelp.hlp in my FoxPlus folder:

NOFOLLOW	- allows a record pointer to move according to 		  the old key value when a key field is changed 		  in an indexed database.

In the FPD26 and FPW26 folders, I found FoxHelp.dbf (&.fpt). They opened in VFP9 ok, but could not find any instances of NOFOLLOW.

HTH If this helps, we're all in trouble.

Steve

 

[Chris Miller]

Steve, thanks.

If I understand this correct it is about existing records and fixes them in their position as it was by their old value when you change a value that's indexed.

It says nothing about new records, but it would mean it sorts by the index "snapshot" that existed initially before any editing. Since a new record wouldn't be part of that index snapshot the question is how it's treated. Strictly speaking it should disappear as a recno not in the index at all, but perhaps it's treated as sibling or child of the last index node, which would make it stay at the bottom, usually.

Chriss

 

[Steve Meyerson]

Hi Chris,

I didn't say what the definition meant because it is not clear to me at all.

Let's say I opened a browse window for a large indexed table. The top record shows "aaa" in the key field. I change it to "zzz". Do I see the changed order? If not, does the record arrow go out of sight? Or will I now be looking at the bottom of the file? Just curious.

Steve

 

[Chris Miller]

You could easily do that.

As far as I tested zzz stays on top even though the index value changed and it should be sorted down, but the sorting and moving occurss as if the index didn't change, that means the old key value is used to sort and also to find next or previous record when you move from the edited row.

But it also doesn't move down without NOFOLLOW.

So I think the NOFOLLOW behavior is standard in VFP.

Chriss

 

[Mike Lewis]

Thank you all for your replies and for the interesting discussion.

Eric, thanks for the link to the dbase.free documentation. This more or less confirms what I remembered.

I also found a reference in my old Foxbase Plus 2.10 manual (from May 1988):

NOFOLLOW
The NOFOLLOW option pertains to index files. If you issue the NOFOLLOW option before changing a key field's contents, this record is repositioned in the file and the record pointer then points to the record that took the place of the original modified record. Without the NOFOLLOW option, the record pointer follows the modified record and, thus, continues to point to the newly modified record.

As I mentioned above, my own testing has been inconclusive. The reason might have been that I was using INSERT in my testing. From what Steve and Chris have said, the relevant behaviour occurs when you change an existing key field rather than insert a new record. I haven't got round to testing that yet.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Thanks Mike,

that description now makes much more sense of the meaning of "follow". So either browse/grid follows where a modified record is sorted and you likely jump away from the visible rows (ie when editing something from the start to sort at the end) And nofollow means you stay local and the edited record would jump away from sight.

I can see that one or the other can make sense. If you want to edit a group of rows and modified values move them far away, the NOFOLLOW option becomes helpful, without it, you'd need to scroll back to the group of records you want to edit.

And in another situation, where you'd like to edit more than one field, it is more helpful to follow the repositioning of the record. I think that's no problem, though, as moving within a row in a buffer mode, even only row buffering, you don't trigger the move of the edited row until you leave it.

I didn't observe the following behavior, as I said VFP seems to work in Nofollow mode no matter if you use the option or not, both in browse and grid. Though I remember this was behavior I earlier tried to tame by introducing sort column that's simply populated by a sequence every time the SET ORDER changes to some specific sorting index. After the sequence is written, SET ORDER is set to that series and since you never edit it, the rows stay in that order no matter how you edit them and so record pointer does not need to follow as even edited rows that should sort far away stay where they were with the old value.

That differs from nofollow behavior, though, in that the visible rows of the grid don't just stay put where you are, also the edited row doesn't jump out of view and there is no need to follow it, even if you would like to stay put on the row you edit. I think that's even more user friendly, and it's easier to communicate to users than it seems. Both the move to "new neighbors" and the edited row moving from sight while you stay "in the neighborhood" are behaviors that can puzzle users. Seems most users think of sorting as just happening when you actively do so, but an index change should usually have immediate effect to sort rows.

New records are a topic of their own, too, because from the user perspective you usually consider them as not yet sortable when nothing was entered to them and you expect them to append at the bottom and stay there.

Well, overall I think the users expectations differ also by what they are used to, but a majority of users I had needed that specific sort index implementation. As it seems something changed in VFP standard behavior by now since the default behavior is almost what I needed and there's little to do to get the specific nofollow behavior combined with a "no move" behavior of edited rows.

Chriss

 

[dbMark]

It' been a long time for me no visit (Get it? NOFOLLOW... NOVISIT ?)

NOFOLLOW was used in BROWSE (perhaps in EDIT too?) so that you would not lose your place in the current or displayed view order and the changed field that was indexed would move it away to it's new index position. If not used, then changing an indexed field would jump you to the next record after it was moved to the new index position. I often used it because often after a field change you wanted to remain in the current displayed order, although the changed record would move or disappear.

 

[Mike Lewis]

Thanks for that, dbMark. It confirms my understanding.

You mentioned EDIT. I would expect EDIT ... NOFOLLOW to work in exactly the same way as BROWSE ... NOFOLLOW, given that EDIT is really the same as BROWSE but with a different appearance. But I haven't tested it. (That said, EDIT ... NOFOLLOW does not produce an error.)

Welcome back to the forum, by the way.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads