>>Fine, but these facts need to gathered in their own method call done before the Add or Delete attempt. I guess I could make a clearer strategy recommendation if I better understood a situation that would dynamically change a client's ability to Add or Delete a record.
>
>A floor of a building has 500,000 sqft of rentable space which can be configured to any number of suites of any size. A new record is created for each suite and assigned a sqft number not to exceed to remaining number of sqft. After all the footage has been assigned, no new suites can be created - hence, no more inserts.
>
>Say the above example applies to booth space for a trade show and you want a road team out there selling variable footage booth spaces in real-time over an Intranet.

oFloor = CREATEOBJECT("MyBuildingServer.Floor")

lnAvailableSpace = oFloor.GetSpaceForFloor(25)

IF lnAvailableSpace > MIN_SUITE_SPACE
* Do something to enable the insert button in UI
ENDIF

This call is made when the UI is constructed. The call passes the floor number, and does not depend on any other properties. The front-end tier then deals with enabling the Insert UI element. Later, when the client requests to add a suite, the server will have to check again to see whether the space is still available:

lnSuccessCode = oFloor.AllocateSuite(lnCompanyID, lnSquareFeetRequested)
IF lnSuccessCode <> SUCCESS
MESSAGEBOX("Sorry, Charlie, there'e no more room")
ENDIF