Skip to Content.
Sympa Menu

freetds - Re: More on using FreeTDS on a server (was Re: [freetds] Server dumpscore...)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Steve Kirkendall <skirkendall AT dsl-only.net>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: More on using FreeTDS on a server (was Re: [freetds] Server dumpscore...)
  • Date: Tue, 20 Apr 2004 11:22:04 -0700

"ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com> wrote on Monday, Apr
19, 2004:
> > * Can anybody recommend an alternative ODBC/TDS driver for Windows?
> > One that, maybe, would give better error messages? Or it would also
> > be okay if it simply worked, I suppose.
>
> As James said ODBC compile under windows. Also you can enable logging.

Okay, Windows isn't my native environment so please be patient with me...

I started VC++ 6.0, loaded the win32\msvc6\FreeTDS.dsw workspace, and
ran the "Build->Build FreeTDS.dll" menu item. This resulted in a
file named win32\msvc6\Debug\FreeTDS.dll. Is that the ODBC driver?

If so, how do I install it? I tried copying it to the %windir%\SYSTEM
directory (in Windows98), and running a series of ODBCCONF commands
similar to what MyODBC (part of MySQL) uses. This resulted in FreeTDS
appearing in the list of ODBC drivers, but any attempt to use it results
in error 1157, whatever that means.

> > * I have a log, produced by FreeTDS, of the network traffic
> > in my failed
> > attempts to access my little SQL server via Microsoft's ODBC driver.
> > Does anybody out there have a similar dump of a *successful* login?
> > Nothing fancy, just a TDS4.2 login such as the "test connection"
> > button in the ODBC Microsoft SQL Server Setup dialog.
>
> It would be useful if you zip&mail the log..

I doubt it. The log file is very tiny, and ends abruptly after the server
sends its login response. But I'll attach it anyway -- maybe you can see
something that I can't.

> > * Are there any common "gotchas" when sending numbers? It kind of
> > looks like tsql is printing the addresses of the numbers, instead
> > of the numbers themselves -- the values are all similar, but never
> > identical. I don't think it's an endian thing.
>
> If similar they can't be a endian problem...

This is fixed now! I had one too many &'s in the row handling code.
I can now send tables with strings, ints, and floats flawlessly to the
tsql program.

> you should use tds_set_column_type
> see tds_add_row_column_size and tds_process_col_fmt in token.c

I'm now using tds_set_column_type(). The tds_add_row_column_size() and
tds_process_col_fmt() functions don't seem to be critical yet, though
when I add support for DATE, TIME, and TIMESTAMP data types I'll probably
need them.

> quite strange code... if I understand you don't use our row buffer but
> rewrite column_offset and current_row...

That's right. Documentation is not FreeTDS's strength, so I modeled my
code on the src/server/unittest.c program, which simply returns a table
with one column and one row. It uses its own row buffer (just a string
for its trivial table), and doesn't use tds_set_column_type() or any
of the other functions you mentioned. I've had to guess on a lot of
this. All things considered, I'd say this has gone pretty smoothly.

> Why don't you join to FreeTDS group to improve our (rudimental and not
> working) server ??

I'm interested, but a bit hesitant just because my time is limited.
At work, I'm about to start a huge project that must be done in 3 months
for a trade show. What little free time I have will probably be spent
working on Elvis, my open-source vi clone.

I will share whatever I get working though. The big issues I've
encountered so far are:

* The unittest.c program uses an initialized TDSLOGIN structure; it should
use a pointer to a TDSLOGIN, and call tds_alloc_login() to allocate an
initialized structure.

* There's no way for high-level functions to know what type of packet is
received, because the tds_read_packet() function discards that byte.
I added an in_flag field to the TDSSOCKET structure, and modified
tds_read_packet() to store the packet type there. (Clients don't care
because the server always sends 0x04 packets after login. But servers
need to know the packet type because that's the only way it can tell
the difference between a query and an RPC call. Also, it should allow
your server to handle TDS4.2 or TDS7 login packets equally well.)

* The tds_get_query() function seems to expect a 6-byte header at the
start of each query, but queries (at least the ones from tsql) have
no header. To find the query's length, check the packet length.

--
Steve Kirkendall |A:It is confusing, since people don't read that way
kirkenda AT cs.pdx.edu |Q:Why is top-posting bad?
|A:It is adding comments to the top of a message
|Q:What is top-posting?

Attachment: foo.log
Description: Binary data




Archive powered by MHonArc 2.6.24.

Top of Page