This months Linux Journal has an article on using FreeTDS with Perl. Didn't even know it was coming until I saw it. Pretty cool.

In other news, I've almost got Access 2000 support working in MDB Tools, and OpenDRDA is making slow steady progress with the beginnings of a ODBC driver.

Someday I'll get back to working on my TDS dissector for ethereal, but that's been tabled for the moment.

Started working on a new project, for now called "libdrda". I'll come up with a snazzier name later.

The basic premise is this: IBM a couple of years ago submitted DRDA (Distributed Relational Database Architecture) to the Open Group standards process. Basically, what it is is a protocol similar in purpose to TDS, SQL/Net, etc... that allows database clients to talk to database servers. But DRDA goes a little further and defines the ability to coordinate transactions across heterogeneous servers which support DRDA natively or via a gateway.

DRDA comes from the mainframe world and uses all kinds of mainframe terms in the documentation...really confusing for a unix guy. However, I've managed to plow through the documentation and get my program exchanging supported attributes with a IBM DB2 7.2 server (DB2 UDB supports DRDA natively in addition to its private protocol).

So, now I have (or will have) something analogous to FreeTDS for IBM DB2. I'll add an ODBC layer on top of it, so it works with Perl, PHP, etc... The next step is to create a DRDA gateway for FreeTDS so that a DRDA client can talk to Sybase or Microsoft SQL Server.

But the real payoff comes from embedding DRDA support in all the open source databases, Postgresql, MySQL, mSQL, Interbase, etc....

Imagine that you could use a single database client to talk to *any* database regardless of vendor. Standards are wonderful things aren't they?

Released tarballs for FreeTDS 0.52 tonight too.

Been doing alot of work on MDB Tools lately. I actually have a SQL engine up and running! This is my first big lex/yacc project, and I'm quite pleased with how easy they make life once you learn them. A few problems here and there but nothing big.

Anyway, finally figured out how Access stores its indexes. Not pretty at all!

On other fronts the dying corpse of Northpoint has left me cursed to dialup. My ISP tried to re-apportion the line to another DSL carrier but no one else comes out this far...argh. So, next saturday I get a cable modem. I hate the cable company with a vengence. They're charging me $10 more a month because I dropped their sorry cable service two years ago and got a dish.

Finally strung CAT5 to the basement and bought one of those linksys DSL routers (Yeah I know I could do it with a spare linux box, but I didn't really want a box on upstairs 24x7, and her office where the DSL line comes in is crowded already). The linksys is working pretty nicely.

I'm getting about 620kbps transfer rate off the supposedly 784k DSL line, but by the time you factor in IP overhead it's probably about right.

Released FreeTDS 0.51 this week. So far so good. Need to automagically find the 16 and 32 bit types for the platform it's built on. inttypes.h provides them on many platforms, but not all and where they are defined seems to vary a bit. glib using some sizeof macros to do it, so I'm probably going to follow that unless anyone has a better idea.

Also been working on a TDS based connection pool program. It works like this. Let's say you have a 10 CAL license for MS SQL Server and want to use Apache/PHP to pull data from the server. Now most likely you'll have many apache children (in a heavy traffic site anyway), more than the number of CALs you have. And more often than not they will not be querying the database at any particular time. So what to do? buck up for a 50 CAL license? pricey.

The TDS Connection Pool sits between the Database and the PHP (or whaterver) clients. It acts like a MS SQL Server, a client logs in and gets a forged login acknowledgement and thinks it connected. Meanwhile the pool maintains a group of logins to the real dataserver and when a client sends a query, it allocates a connection, forwards the query, forwards the response back to the client and then returns the connection to the pool. This has the additional advantage that the client-to-pool connection is very quick compared to the long connect time to the real dataserver, so you get the advantage of persistant connections without the disadvantages of having one connection per Apache child like PHP.

Working on FreeTDS bugs...Microsoft decided under SQL Server 7 to change the default packet size which has caused all kinds of havoc with large querys. I'm glad to finally have a handle on why though.

Been comtemplating how best to debug with a complex system like apache+PHP+FreeTDS+SQL Server, Problem is when you have 30 httpd children running around and you have an intermittant bug it's damn near impossible to catch it. Best I've been able to do is generate tons of logs and hope something gives.

Skipping the presidential debates tonight, think I've seen enough in the first two. (Go Nader!)