Skip to Content.
Sympa Menu

freetds - [freetds] dump file is per-spid

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: 'TDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: [freetds] dump file is per-spid
  • Date: Mon, 15 Dec 2003 16:32:07 -0500

I bumped into unexpected (to me) behavior with TDSDUMP.

If a single process opens two db-lib connections, the dump file is reopened
when the second connection is established. Our documentation says this is
"process" related; I assumed "process" meant client process, not spid. [1]

I can see why we wouldn't want several client processes recording to the
same log. But I think it's a mistake to initialize the log every time we
connect to the server. I can't see what use that is.

For db-lib, we should probably initialize the log logically during dbinit().
For ct-lib, ct_init(). For ODBC? I suppose we need a tds_init() for them
all to call, as long as it's not an error to call tds_init() multiple times.


It occurs to me that client-side iconv initialization could be per client
process, too. Right now, it's per-connection.

I suppose this is all 0.63 stuff. Any comments on my proposed
functionality?

--jkl

[1] The workaround is "dump file append" in freetds.conf. But it's not
wonderful. Subsequent connections record the TDSDUMPCONFIG output to the
file (even if not set). And the second connection interrupts the first's
output, I guess because we have two (or more) handles writing to the same
file and don't coordinate flushes.



-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the original
message. Please note that we do not accept account orders and/or instructions
by e-mail, and therefore will not be responsible for carrying out such orders
and/or instructions.






Archive powered by MHonArc 2.6.24.

Top of Page