Skip to Content.
Sympa Menu

freetds - Re: [freetds] odbc isql

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] odbc isql
  • Date: Sun, 10 Apr 2005 11:55:08 -0400

"ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com> wrote:
> I'm not that happy to include an isql in FreeTDS, it seems a
> duplication. Normal ODBC programmers should use DM and is a bad idea to
> distribute an ODBC example that do not use DM. However I must say that
> writing tests is very hard and a way to script them would help a lot.
> Perl is not a good solution cause it not easy to have right
> perl/DBI/DBD::ODBC installed.

Our goal is to have a better way to test our driver, yes? If we use
DBD::ODBC or even the DM's isql, we introduce layers of other software
into our tests. That's why we need a script processor linked directly to
libtdsodbc.

I don't care where it comes from. I looked at the iodbctest program; it
looks better than my effort so far with the unixODBC isql. Maybe we
should use that instead. We don't have to maintain it in CVS; we can
simply include it in the distribution.

I propose we put our script processor in apps, and call it bsql-odbc. No
one else would choose such an ugly name. For support, it would serve the
same purpose as tsql and bsql-dblib: a standard frame of reference for
programming questions and testing query processing. We can also call it
from src/odbc/unittests to make that job easier.

> It seems that DMs are quite different so (as anyone can see) tests
> present small differences using different DM...

Yes, but that is a different question. First is to get driver behavior
right, that there be *some* way to get correct results. Then we can
resolve DM issues. (I realize that DMs sometimes replace driver-provided
functions. I think having a clear window into how libtdsodbc without the
DM will help isolate DM issues.)

> Also keep in mind that many tests require different way to get data. You
> can bind data before or after query, prepare or not the query, fetch
> data with binding, use SQLGetData (or a mix of the two or not fetch but
> only skip rows..), read column/row number or not, read all rows or
> not... Your "isql" have to be capable to combine all possibility.

That is certainly an argument for having our own processor. We could
include different fetch approaches and call them all. We could also merge
in my odbc_rpc code, so the query processor could also exercise the rpc
logic.

> Also
> different db engine versions (sybase, mssql or even the same but
> different version) have different behavior (ie ASE 11.5 support
> DATE/TIME).

I'm not familiar enough with that to understand the ramifications. But
from looking at the iODBC iodbctest and unixODBC isql, I don't see any
difficulty. If you mean they render dates with different string formats,
I think we can cope. We should look forward to the day when that's the
major problem.

It might even be a good idea to do both. We could include iodbctest (it's
BSD) in the distribution as iodbctest-freetds, unmodified, linked directly
to libtdsodbc. And we could hack our own bsql-odbc for more specialized
work. When something doesn't work, we'd have two tools to try it out on,
plus whatever the DM provides. When the DM's version and ours disagree,
we'd have data points to triangulate.

What do you think?

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page