Individual File Overrides - A One-Way Ticket to Confusion?

Perhaps not an easy situation to describe but will give it a shot.

For a half dozen or so tables in my DCT, I long ago (turn of the century) declared the use of an alternative ABC FileManager class (ie.MyFileManager) on the Individual File Overrides tab.

After completely moving the added functionality into PostgreSQL triggers for these tables, I have been trying to remove the use of the alternative FileManager class from the data dll APP for these tables without success. I believe this is due to the template symbol %ABCBaseClass (dependent upon %File) continuing to hold the value of MyFileManager rather than being cleared to allow use of %DefaultBaseClass.

Exporting to TXA verifies the values in the symbols. Furthermore, making changes (or even no changes) in the TXA and reimporting yields a wonderful ~1800 errors.

Might anyone have suggestions?

Export your data dll to TXA. Search for %UseDefaultABCBaseClass DEPEND %ClassItem LONG TIMES

Go to the WHEN (‘FileManager:’) entries and change any that are (0) to (1).

Import the TXA back into a new APP and give that a shot.


That was exactly what I thought would be the easy fix. The problems:

Interestingly, there are 4 sections in the TXA with
%UseDefaultABCBaseClass DEPEND %ClassItem ### TIMES
In one section only, the value for the symbol is correctly set to True for the desired tables.
In the other sections, the value remains False.

No matter what changes I make (or perhaps no changes at all),
I am unable to import the TXA without getting ~1800 errors.
So far, sorting these errors down to a couple of logical explanations has escaped me.
I have imported TXAs into non-data App files many times without problems so have to wonder what is different.

Why not cheat :grinning:

Edit your MyFileManager class so it’s the same as the default (removing any extra methods/triggers etc).

Sometimes it’s just better to let Clarion think it’s won and workaround it’s ‘features’


1 Like

Funny you should mention it. In effect, that is what I did in order to work around the issue.

Nevertheless, the clean developer in me wonders why the TXA contains:

a) Four sections for symbol values
b) Values for every table name ever defined in the DCT (rename a table, get 2x the values).
c) Unable to import even an unchanged TXA