>This is saved in foxuser.dbf/fpt. What you could do is move the current foxuser files to a temp location or rename them. Fire up FP 2.6. Browse each table and put the columns in the order you want. Close the tables. For a test, open 1 table and issue a BROWSE LAST from the command window. The columns should come up in the order you set. Provide that set of foxuser files to the users.
>
>Now the big problem -- you will have to modify all the code so all the BROWSEs are BROWSE LAST commands.
>
>Unless you can hack the QM DD and sort it, you are stuck using whatever they provide. If QM stores its meta data in a text file, you could make a copy of it, import into VFP, sort it, then export it back to a text file. If QM fails. replace the sorted file with the backup copy.

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?