Well, OK. But that DBF deleted mark still gets me into trouble when I have to work with multiple developers (if I had $.10 every time someone had "SET DELETED OFF" when I had "SET DELETED ON" in our IDEs, I could retire now).
Steve : "We have 2,000 payments"
(nameless) : "we have 2,200 payments, you lost 200 in your query, what are you doing, you just lost $(nameless amount).
Steve : "Set your deleted on"
(nameless) : ".....oh. Well, I just emailed the client that we had 2,200 so I guess I have to email them again..."
Steve : "!"

When I am trying to reconcile between an on-disk ADO recordset/VFP/MSSQL and using XML to pass the data, everybody's concept of "deleted mark" is different - but they all know Int...

The other thing I get with an Int is multiple states of deletion. In my last job, we needed to have undelete capability for a table. So I just added a state of "2" in the iDel column for things that were deleted but subsequently recalled. The table relationships were pretty complex, so I didn't want to create a complete mirror image of the table with just "undeleted" rows. I just added the "2" value and a child table with a little undelete-related info and I was moving.


Actually, when it comes to supplementary columns, I have all of these on every table I care about:
  iID (candidate key for uniquely identifying a row)
  iDel (deletion state)
  cDelU (name of user that did deletion)
  tDelDt (datetime deletion was done)
  cCrUser (name of user that did row insert/creation)
  tCrDt (datetime row insert/creation)
  cModU (name of user that did modification/update)
  tModD (datetime user did modification/update)
When I xmlize the cursors, or just look at them in any environment, I always know who/what/when happened to a row - I guess it's a little paranoia {grin}, but those seem to be the questions I get that I can't answer fast enough.