I hope some guru can give me a positive answer to this....

Is there a way of setting up the TFILE lookup to always look back into
the file that is being processed without actually specifying the
actual file name in the correlative?

I'm trying to create a few files that have the exact same data
structure but different file names. I would like to create one TFILE
that would work on all the files without having to change the filename
in each set of dictionaries. I could be changing a Q-pointer to point
to the file I want and I would like the data to be retrieved from the
actual data file the is being used in the process.

The other thought here is to have one dictionary with many data files
attached and have the one dictionary TFILE retrieve data from the data
file that is being used to list/select data from.

Anyone out there willing to take a stab at this one?

Does this posting need clarification?

Regards,

Dale

On Mar 21, 6:11 pm, "Dale" <dale_bened... (AT) flightcraft (DOT) ca> wrote:
Does it have to be an actual tfile? Could you do the same thing with a
call to a subroutine and use the relevant access() function?

Mike.

Dale wrote:
Easy on UniData, but I don't think you are running that.

What O/S?

--
frosty

On Mar 21, 12:19 pm, "frosty" <fros... (AT) bogus (DOT) tld> wrote:
OS is D3/Linux (it is in the subject line)

I was hoping to not to have to change the tfile lookups! This would
be extremely handy for dictionaries with multiple data sections.

I have a feeling that since the most requested update to D3 involve
the change to the TFILE to bring back a multi-valued list, asking for
this enhancement would equally fall on deaf ears.

Regards,

Dale

I'm with Mike on this one; I think you are going to have to use a call
correlative and do the lookup in basic. Access(2) = file variable for
data file, access(11) = file name. You should be able to use either
one?

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

"Scott Ballinger" wrote:

Agreed. In D3 there's no such thing as a dynamic reference to the
'current' file, and we can't build a translate or other correlative
dynamically at runtime. This would be helpful in MANY applications.

Sorry that answer isn't different.

However - for better or worse, it would be trivial to write a trigger
or similar process which updates a list of dict files with
file-specific customizations whenever you update some master
definition. This would transparently simplify your entire dict update
process. Without using triggers a simple program could handle the
same operation.

This is one of those situations in Pick where we don't truly "need"
the DBMS to include some feature because it would be dirt-simple to
just do it ourselves, and perhaps more elegant than a run-time call
from a dict-item.

HTH
T

On Mar 22, 5:11 am, "Dale" <dale_bened... (AT) flightcraft (DOT) ca> wrote:
ummmm, if you want to translate back to the same file, errr, ummm, why
do you need a translate in the first place ?!?! Why not just setup a
standard dictionary item? or is that too obvious?