OK I've read the E-mail announcement and the posts on the BBS. I also see in the news that IBM is entering into negotiations to buy Sun; you may have an easy path to DB2 (or even C-ISAM) in the future!

MySQL directly uses ISAM with the MyISAM engine by default. Would it even be possible and desirable to change ISAMPlus or "original (A-Shell)" ISAM to use MyISAM directly?

Because MySQL access to data is handler-driven, isn't it possible to write a handler so that MySQL can directly utilize the ISAMPlus (and/or ISAM) format? No data duplication unless replication is implemented, but in that case duplication is wanted by design, say, to put data on a web-facing server.

I check into C-ISAM and D-ISAM handlers for MySQL every now and then, and while I see much desire for one, nobody has actually written the handler, or if it has been written, hasn't released it. (OTOH I have seen Informix' embedded SQL for C-ISAM, and Byte Designs SQL (via CONNX) for D-ISAM.) Some say that there're enough clues in the ha_myisam sources to create a handler for any ISAM engine.

Please note that I am not volunteering to write an A-Shell ISAMPlus nor ISAM handler ;^)

Hi Mike. You really had me interested there until your last sentence!

Regarding using the existing MyISAM engine as a way to emulate C/D-ISAM, the last time I studied that option, it seemed that there were still enough limitations (particularly in the area of record locking) that I was afraid we end up with something that was interesting, but not quite good enough to replace the existing ISAM options. It's possible that has changed recently, so perhaps I should do some more research. Certainly, having a D/C-ISAM handler for MySQL would provide a very nice way for people to migrate existing ISAM-A code to MySQL (although then it would be even more painful when they request, as they inevitably will, that we offer the same feature for SQL Server).

As an aside, we once had (and could revive) a subsystem that implemented ISAM-A on top of ODBC. But the feedback was that it was just too slow for production use. The CONNX and Easysoft approach, other than their high cost, made more sense to most people, in that it didn't affect the existing ISAM-based performance at all, and instead put all the cost on the users that really wanted/needed SQL query capability.

So my sense is that although some people would like to be able to throw a magic switch and have all their data suddenly in an SQL database, accessed by their existing unmodified applications, the thrill wears off when one discovers that ODBC isn't particularly efficient for the kinds of record-level, navigational ISAM operations that are typical within existing applications.

Our objective with SQL.SBR was really quite different, i.e. to provide a new "natural SQL" interface to enable people to write new code based on SQL logic, rather than to provide a simple migration path for existing code. But that's not to say that the complete migration goal has gone away, and I fully expect we'll be talking about it again before long. (In fact there has already been an interesting discussion along those lines, coming from a completely different angle - file I/O hook functions - http://www.microsabio.net/ubb2/ultimatebb.cgi?ubb=get_topic;f=5;t=000875 - that may end up getting some traction.)

There just aren't enough hours in the day to fully comprehend and evaluate all the possibilities, but I certainly appreciate your feedback and suggestions.