FreeTDS Development Group

["Charles Bearden" <Charles.F.Bearden AT uth.tmc.edu>]

> -----Original Message-----
> From: freetds-bounces AT lists.ibiblio.org [mailto:freetds-
> bounces AT lists.ibiblio.org] On Behalf Of Lowden, James K
> 
> > From: Charles Bearden [mailto:Charles.F.Bearden AT uth.tmc.edu]
> > Sent: April 28, 2004 12:41 PM
> >
> > When I try to
> > load a chunk of Unicode into an ntext field in some records,
> > the program
> > raises an exception due to a "function sequence error".
> >
> > I have built and installed the following:
> >
> >   mxBase-2.0.5
> >   mxCommercial-2.0.6
> >   libiodbc-3.51.2
> >   freetds-0.62.3
> 
> Hi Charles,
> 
> I'm unfamiliar with mxBase and know Python only from a distance.  I
offer
> mere speculation.

Many thanks for your response.  I am interested in getting this setup to
work, and if in the process an issue with FreeTDS is discovered and
documented or a bug found and squashed, and I learn something, so much
the better!

> The "function sequence error" might refer to an ODBC error meaning
"you
> called funtion B without calling function A first".  We have, in the
past,
> found some cases in the FreeTDS ODBC driver whereby it expects an
A-B-C
> calling sequence, but the ODBC spec says B is optional.
> 
> Unfortunately, there's no neat trail of the calling sequence in the
log.
> If particular records cause the application to call FreeTDS
differently
> for some reason, that might not be clear from the log.
> 
> The error message emission logic should write a message to the TDSDUMP
log
> in addition to returning an error to the caller.  If an error came
back
> from the server (unlikely, based on your description) it would
definitely
> be logged.  I'd look for something along those lines.  Since your log
is
> probably huge, perhaps you post a relevant chunk or put it on a
website
> somewhere?

I copied one of the problem records to its own file and ran the program
against it so as to produce minimal output.  Here:

  http://acad24.sahs.uth.tmc.edu/tdslog/index.html

you will find the complete log (proc2err.log.txt, 6589 lines) and the
log starting with the packet calling the stored procedure through the
end (tdsdump.log.txt, 977 lines).

> > The error is specific to particular records.  In one file, it is the
> > 11th record; in another, the 142nd (which also means that 141
records
> > are successfully loaded before the error occurs).
> 
> By "specific", do you mean specific to the data, or specific to the
order?
> IOW, if you move the 11th record to be first, does it still break?  (I
> bet: Yes.)  

As implied above, a problem record in a file by itself causes the error,
so it does seem to be order-independent.

>             Is that record especially large or somehow different from
the
> others?

I think you have hit it.  I confess I neglected to test on length, since
the record in question is only 8200 bytes long--not a big chunk in my
mind.  However, I split out each record from a file of 5000 into a
separate file, and the 11th record in that file (one of the problem
records) is larger than the preceeding ones.  What's more, the problem
is reproduced with the 19th record, which is even larger, but not
reproduced with the 5th and 18th records, which are a little smaller.
You can see the list of the first 20 files from 'ls -l' on the page
named above.  I apologize for not having considered this possibility
more seriously before posting.

Is there a way to enable me to load moderately large chunks of data
through FreeTDS?  I'll also check the docs again myself, but advice from
list members is also welcome.

>          Perhaps its an encoding issue.  Maybe there's a unicode value
> unsuitable to your client character set.  Or maybe this advice is
worth
> what you're paying for it....

If I and others are edified by this problem, then it's worth a good deal
more than I'm paying for it :-)

Chuck Bearden
Systems Analyst III
School of Health Information Sciences
University of Texas at Houston
713.500.3954 (voice)
713.500.3907 (fax)
Charles.F.Bearden AT uth.tmc.edu