Skip to Content.
Sympa Menu

freetds - RE: [freetds] Logging

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'freetds AT lists.ibiblio.org'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Logging
  • Date: Tue, 14 Jan 2003 13:16:04 -0500

> From: Martin Spott [mailto:mas AT plesnik.de]
> Sent: January 14, 2003 11:05 AM
>
> > Anyone who sends good feedback plays a useful role.
>
> BTW, I managed to crash StarOffice while connecting to the
> database on the
> local server: It somehow depends on the server release and/or
> setup details.
> I set up a stock '11.0.3.3 ESD#6' on my local machine and now
> I get the same
> results as when connecting to a 11.0.3.3 on a remote machine.
>
> Anyone interested in logfiles ?

I think atm we've got all we can use. I added the list of missing
SQLGetInfo types to our TODO.

Given the long list of missing SQLGetInfo types in your January 8 log, it's
clear Star Office is requesting quite a few things from FreeTDS that it
isn't getting. It's likely that Star Office fails to notice one or more of
the errors, and/or ignores one to its detriment later on (when it crashes).
It's easy to imagine that it requires reasonable output from, say,
SQL_CATALOG_USAGE or SQL_NEED_LONG_DATA_LEN prior to
SdbODBCConnection::FillTypeList().

Show me an application that crashes when using an incomplete driver, and
I'll show you an application that behaves badly. AFAIK, FreeTDS told Star
Office the (unpleasant) truth, and in a perfect world they would have
handled it gracefully. Alas, no. You might want to tell them; I should
think they'd want to see the bt. If they point out an error in our
implementation, we will fix it, absolutely.

Meanwhile, stay tuned. As we implement those types, we'll cross them off
the list. If we get to the bottom and it still breaks, we'll have to look
more deeply.

--jkl


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