>I've been thinking a lot about date-sensitive datebases. You give the system a rundate and ask for a report and you get the same report that was originally produced on that date. This requires not only keeping all of the detail records with an effective date on each but keeping master records as a set of records with effective dates. E.G. I change the address in my ADDRSS record. The old record doesn't dissapear; it just gets overshadowed by the new record with a more recent effective date. Unless I tell the system that the date is before I made the change--then the system gives me my previous address.
>

I've seen this done before but it's a real pain to code and can lead to some real nightmares in a pure relational model (SQL statements in particular).

>A logical extension of these concepts is to store all of the business rules in the database also with effective dates. Then the data can be consistent with the rules at any given point in time.
>

A problem with this is that while it's easy to store parameters for business rules within tables its doggone difficult to store logic. The current mode of thinking with OOP and VFP is to encapsulate business rules in business classes...methods are called in these classes to calculate/validate data. Now, let's compare that to COM (Component Object Model) theory. It states that you can add new interfaces (methods, procedures, whatever) but should never remove them. Kinda fits in with the effective date concept, eh? A simple example that shows both data-driven business parameters and OOP driven business logic.

BizClass is your Custom class with the business logic.

oBizLogic=CREATEOBJECT("BizClass")
nWidgetTax=oBizLogic.CalcWidgetTax({04/14/1998},10)
....

PROCEDURE CalcWidgetTax
LPARAMETERS dDate,nQuantity
USE bizdata AGAIN IN 0
LOCA FOR typedata="WidgetTax" AND effective <= dDate
IF !EOF()
nReturn=bizdata.nvalue*nQuantity
ELSE
nReturn =0.00
ENDIF
RETURN nReturn