>Would you have a property in your button set class to hold the view/table alias that your actions can use to be sure they act on the correct table alias?

Yeah, that's the usual way. I have done it another way though...
I have a generic 'deletefromgrid' button that I drop on a form and just set the name of the grid on the same form that I want the button to delete from. I approached it this way so the button could also automatically take care of the refreshing of the grid, and also set focus to the grid to take care of updating the pointer. A vastly abbreviated summary of the code goes like this:

cmdDeleteFromGrid.Click()
oGRid = EVAL('THIS.Parent.'+THIS.GridName)
IF THIS.BeforeDeleteAction()
    DELETE IN (oGrid.RecordSource)
    THIS.AfterDeleteAction()
    oGRid.Refresh()
    oGrid.SetFocus()
    THIS.SetFocus()
ENDIF

It works beautifully, and is really flexible. You could do the same for add and revert button classes.

>What preference to you have on using views vs tables on a maintenance type form (low user count environment)?

It really just depends on your preferences. Tables are fine if the data is not so normalized as to be meaningless to the user, and if you know the app/data will never be client/server. If you need to present data from several tables in one meaningful cursor, or if your tables are really large and you need to be able to narrow the results down, then views are the way to go. I personally use views almost exclusively, but this doesn't mean it's the only way to go.