John,

I read this massive book regarding COM, and one of the things that "stuck" was the (alleged) "standard" to always have a version number (or something quite similar) in the "registry", thereby (allegedly) allowing multiple versions of the same object to exist in the same system.

The theory was along the lines of older apps would know and recognize and look for the older "version" while newer ones could use the newer one. There was even some bit to say if the new *could* be treated as an 'old' or not.

But, as we have seen, even MS does *not* (seem) to adhere to this - witness troubles epople have with incompatible versions of treeview or mscomm or whatever!

A comment on "data-driven. . . so I'm contracted to work on this "table-driven" system. Should be interesting, I thought. But there, throughout the code, were hard-coded all manner of distinct values. Yes, stuff was in tables BUT *not* the 'meaning' of the stuff. That was left in the program!

Cheers,
Jim N

>>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