>>...but naming it "INACTIVE" instead of "ACTIVE". It would be most user-friendly to show them the text ACTIVE and then a "Y" or "N", rather showing them INACTIVE and then a "Y" or "N".
>
>If I were designing this I would use a logical field with inactive represented as .T. and would call it "Inactive."
>
>As I input the data I would not need to do anything for an active record since the default of a logical field is .F. Then I would specifically have to set it to .T. to inactivate the record.
>
>The code would read something like:
>SELECT * FROM MyTable WHERE NOT INACTIVE...
>
>It could be shown onscreen as either a checkbox or text with a "Y" mask.
>
>I guess my mind works the same way as this programmer's and your boss'.

On the other hand, the creation of a record doesn't always mean that the record is also automatically "active" ... Adding a new Employee before they have actually started, for example.

Using "Inactive" as a default simply because the "system default" is .F. is imposing the underlying (system) architecture on the User, instead of catering to the User; one of the most common complaints is exactly that: UI's are designed by programmers, and not interface designers.

The merits of Active vs Inactive depends on the application ... There is/was also a general rule that one avoided "double negatives" when creating UI's: "Active or NOT Active" is generally absorbed easier by the public than "Inactive or NOT Inactive".

And since "Active/Inactive" is generally one of a number of mutually exclusive attributes of the property "Status", it could be argued that "New/Inactive", "Active", "Suspended", "Terminated", etc. should all be values of a "Status" property so as to avoid multiple conditions (via input, evaluation or reporting). And sometimes it's easier to add another "code" than another "field".