Rather than defining constants, i have been using a 1 record table. By opening the table, i can use the table.field notation to reference my "constants" If (as management likes to do) the constants change on a whim, the table can be quickly updated without recompiling or issuing a new include file.

I also used this trick to make an insertion routine that allows several different structures to be the source to a common format. Each record of a table contained the Insert Into fields list in one Memo, and the Values in another Memo. The statement was simply Insert Into (table) &iField &iValues, and it didn't matter what the source table looked like. (ex: the default used 10 fields named one thing, and the "REN" table used the same data but with different field names and some exclusive fields not at all)

The pseudo constants table makes sharing the constants pretty easy too. (all the benefits of an Include file, but none of the drawbacks you mentioned.) I guess the only limit would be the number of columns allowed in a VFP table - but if you have THAT many constants, you've probably got bigger problems than how to store them all....