Indeed, indeed, me too.

About the only more obscure thing I've encountered* is when to set a single field that you want to be universally shared to something other than global storage. Every database file I create contains a table called simply "F" (short for "file"), in which I store all the fields that occur only once in the entire file. Normally it makes sense to set these to global storage, since that's pretty much what global storage is for.

But global storage has consequences. One consequence is that whatever value you put into a global field on the host machine is the one that pops up when a guest fires up that file. So if you put in, say, "red", that's what will show up for User X whenever he opens that file, even if it had said "blue" the previous time he used it. The upside of this is that User X can change it back to "blue", and that's the way it'll stay for as long as he's logged in (or until he changes it again). Meanwhile, the original file still thinks that the field says "red", and User Y can set it to "green", and User Z to "orange", and they'll all go happily about their business, each thinking he or she has exclusive control over that field. As, indeed, they DO, as long as they stay logged in.

But every now and again I've got a field that I want to be a truly GLOBAL global — a universally available datum, occurring only once in the entire system, that ANYBODY can change, and have that change propagate thruout the system for all users. For example, "What's the current academic year?". That's a datum that needs be entered only once in any file, so the "F" table is an appropriate place for it, but global storage is not the way to handle it. So I just store it as a regular field. Since there's only 1 record in the "F" table, it doesn't matter whether it's indexed or not.

It took me years to discover this little trick, and I still have to remind myself of it from time to time.

–––––

*tho I'm sure there's stuff even MORE obscure that I haven't yet run across