| I did have a discussion with someone about this behavior, but
not sure it was in this conference.
As you have observed, under certain circumstances various gateways
will create tempoary files with names that typically begin with TDC.
These files are suppose to (will) go away no later then the time
the gateway image exits. On some platforms these files are created
with an attribute like "delete on exit" and on other platforms the
gateway, itself, explicitly deletes them.
In your case I beleive that the following is happeing. You are
using MS Access via ODBC driver (via SQL Services) to access DBI /
DB2 gateway. I suspect that the SQL Services server is configured
in such a way that the DB2 Gateway image does not get run down. For
example, this would be the case if it were set up as a SQL Services
class server with a non 0 value for MAX and some reasonably large value
for IDLE, I would expect the TDC files to stick around for at least
the value of IDLE.
There are a number of things you might do to avoid TDC file problems.
One approach would be to change the configuration of SQL Services (if
my hypothesis is correct) to cause executor images to be run down more
frequently. This may not be desireable if fast attaches are important.
Another approach would be to cause the gateway to not create these TDC
files in the first place. This is the approach I would take. Typically
TDC files are created to support read-only dbkeys. MS Access - ODBC Driver -
SQL Services - DB2 Gateway always requests dbkeys, though it rarely, if
ever requires them. If you alter the dbkey mode to something other then
the default of read-only dbkeys the TDC files will not be created in the
first place. If you are using V7 of DBI and/or Gateways you might have
luck with the new, NON_FUNC dbkey mode. It is described in the "New
Features and Enhancements in V7.0" release note titled "New DBKey Mode
for Gateways: NON_FUNC" (1.17 in the rev of release notes I have.) This
will be the most efficient mode you can choose; it was implemented
specifically for the benefit of MS Access users. But you should read up
on it as there are potentially some limitations. (Specifically, the
internal processing of certain complex requests requires the use of
valid dbkeys - when functional dbkeys are not available the request
will end with an error.)
If you have a pre V7 release (like V3.1 or V3.1A) you will probably want
to use user defined columns as dbkeys, or possibly primary keys as dbkeys.
Either of these 2 modes will be more efficient then what you have now, ie
the default of read-only dbkeys.
DB Key mode is configured by setting certain attach qualifiers, either in
the attach string or, more typically, in a configuration file. This is
pretty well described in the DEC DB Integrator Product Family User's Guide,
but if you have any questions post them here and I will try to answer them.
|