>Browse LAST works as long as nobody else browses the table with the same alias on the same machine meanwhile - then his preferences become the last. There's a way to create a named preference,
>

BROWSE .... PREF [preference name here]

>it will get created if it doesn't exist, and will be used if it does, so all it takes is doing one good browse with desired number, widths and order of columns, and it will be used further on.
>Now the great drawback of this method is that it stores the browse preferences in the resource table, i.e. foxuser - which is not the most safe place. I've seen attempts to use this, and it worked fine while it worked, but any problem with foxuser.dbf simply ruined the whole scheme.
>The only safe way to have our custom-made browses appear the way we want them is to write long-sausage Browse commands, field by field (or invent some sort of builder which will create parts of them on-the-fly) - but then, we may be better off going for the grids in the first place. They have better builders, right?

Yeah, I don't do BROWSE in apps. Too many headaches and data integrity holes. Plus, I don't like to explain to users how to look at raw data.

She said this was a FP 2.6 app so there is not many options. Your mention of the long, hairy browses with all the formatting options/switches brought back bad memories. < g >