Something I don't understand about the business rules interfaces

Data Abstract
1

Hi,

I’m a bit confused about something.

In my data modules, where my TDAMemDataTables are declared, I’m obtaining an interface reference to the associated client rules objects from each of my tables. Via the QueryInterface override of TDADataTable, this returns an interface reference to the contained object fBusinessRules.

What I don’t understand is why, when I either set this interface reference back to NIL or allow it to go out of scope, the reference counting system isn’t destroying the underlying client rules object.

Surely it should but it’s obviously not or I’d be getting access violations?

2

if you want to destroy associated business rules, you should set BusinessRulesID to empty string.

Note: RefCount for Business rules doesn’t work:

function TDABusinessRules._AddRef: Integer;
begin
  result := -1;
end;

function TDABusinessRules._Release: Integer;
begin
  result := -1;
end;
3

No I don’t want to destroy the class, I’m just confused as to why disposing of the interface reference doesn’t automatically destroy it.

I presume the disabling of reference counting via these functions is what prevents this from happening so you can obtain and release interface references without any fear of destroying the underlying object?

4

yes, you are right

5

Thanks, that makes sense now

6

I think this might be causing a weird side-effect whereby, if you store an interface reference in a local variable in your datamodule, for example:

FTestTableIntf = (tblTestTable as ITestTable);

Then, if you clear this reference before the data module is destroyed by just setting it to NIL, everything is fine, but if you just leave it, then when the data module is destroyed, you get a very nasty access violation from within the bowels of the runtime.

Not a problem as such, just need to remember to clear any such references down.

7

AFAIR some versions of delphi incorrectly clear interfaces so better to do it manually when they aren’t needed

8

Yeah we do but had just missed one and I was surprised it was causing such a major problem.