Agreed - I did not say but given the fact that the Inactive field defaults to .F. was just easier. In the framework I use, there are a few more things to set to have something default to .T. - so just easier.

And yes, much much prefer very specifically names fields - which was a challenge when this app only used free tables that were limited to 10 chars. I took care to then at least name the controls that bound to them longer and to also put a note in the control's comments area to be really specific if it still might not be clear. I inherited an app that had next to no documentation and we basically had to scrap it and start over as it was a spaghetti mess of code with no documentation, either in-line or external. So I vowed to this business owner to always go a bit over the top in documenting so that if I dropped dead (or took a never-to-return vacation to Serbia), that someone else would at least have a fighting chance of maintaining the code. It also is a great CYA way of working - how many times have I had one of the owners come (there are 12 partners in the business) and say "why the heck are we doing x" - and I say "give me a second" and I look up what the data is and my notes on it and how it is supposed to behave etc. I did not do that as extensively the first couple of years and I got bit by not being able to explain myself - of course it looked like I was the problem when in reality I always do what one of them want - the only fault was my memory. So fairly quickly in to working for this client every addition or change or delete of data or how it functions gets documented. And it should really make it better for the next person (which most likely will just be me as we move to a new product).

Oh another thing - ever take over an app with "mystery fields" - like ones called "status" and they have values like 0, 1, 2 etc - with no lookup chart to know what they are supposed to mean? I did a data export for someone from one system to another and it was rife with them - had to dig around (no source code) and find the screen that connected to it (if I could) or ask enough users if they knew what the different values meant. A nightmare. In the end, they were able to export to a new system pretty well all of the important fields but a bunch of them were left on the cutting room floor as no one had any idea if they were still used or what.

I think it was a guy names Alan Swartz who did a session at a VFP conference years ago who pointed out to never use "mystery values".

Albert

>
>What Albert said, plus the benefit of default falling on the usual side - if you add a field Inactive, it'll be .f. (or 0) by default (or null, for that matter) so for the majority of cases your user has to do exactly nothing.
>
>For most bit fields, I prefer to have something very specific, including a verb, in the name. With active, which is by itself a boolean value, it may not be necessary, but for a field like PhoneCalls, License, OtherAddress etc, it's IMO much better to call them AllowsPhoneCalls, HasLicense, UseOtherAddress etc. To make it clear. I've seen fields which had me completely baffled as to their meaning, and having a verb in the name would save me ten minutes (with GoFish, or 30 with code ref) to dig out the use and write the documentation for the field. For a field Assistant - would it mean IsAssistant or HasAssistant or NeedsAssistant?