The MulleSybase EOAdaptor Technology Demonstration
(updated 23. March 2001)

This is a snapshot of the ongoing development of the Mulle kybernetiK Sybase Adaptor. The demo is solely there to show people that a working and production useable EOF Sybase Adaptor for Mac OS X Server is feasible outside of Sybase/Apple and also to get feedback on the direction this project should take (see below).

Feedback so far has been one person, who showed interest in the adaptor. Judging from this "market surveillance", I have nothing to lose to keep this more of a demo project than some offical/commercial endeavour. Because of the general lack of interest the adaptor will probably not see a public release very soon (i.e. think months, instead of weeks). It will be used in a commercial project though, so it definetely will be finished.

Anyway the current state is this: Because I was not very happy with the FreeTDS implementation I am now writing a TDS/CT replacement, which allows me to do all sorts of nifty optimizations and lets me address all if not most issues in the disclaimer. At the moment the adaptor fetches as the terminus technicus is "like a screaming mother" but insert/update delete are still very slow, because they are done without bind variables. This will be the next step to implement.

Not using FreeTDS has the unwanted side effect, that the MulleSybaseEOAdaptor will lose compatibility to SQL Server and older sybase products, since it is implementing TDS 5.0. ASE 11.9 works :)

For ye olde demo coderz: Performance wise, the adaptor is now responsible for approximately a third of the total time spent fetching rows. The rest is used up by the EOF. Of that third, only a tenth of the time is actually spent reading from the socket, whereas about two thirds is used up for allocation and autorelease (and there mainly the NSDictionary (ca. 25%)). Even with a final amount of optimization (I have some plans <grin>), the adaptor can not become much faster than 20% of its current speed, if staying single threaded. With optimal threading one could get 30% better. I am afraid that's about it.

Wanna alphatest, when its ready ? Send me an email.

I am sneakily putting this text here in the middle of things fully expecting noone to notice. Basically the adaptor is done - alpha state. Solaris should work, I should fix it up for NT sometime, but that can wait. So i will just ramble on a bit about things. Last weeks were spent implementing the bulk copy routines for the image/text. That wasn't so hard to do, but left a small wart on the design I think. I finally got around to profile raw row fetching performance and I seem to have hit the point, where there is no more room for optimization. If I could implement my own NSZone I could probably get a massive performance boost, but that is now out of the question (because currently you can't do that). The other possibility would involve to completely reimplement NSString, NSDecimalNumber etc.. Foundation Classes, but I am frankly too lazy for that. Chris Kane gave me a hint that in MacOSX I could implement my own malloc/free stuff, so if that is true and works like I hope it will, expect big things to come.

Actually I cheated on the bind variables, though the code is there to do 'em, currently only image/text are done with bind variables, and these special bulk binds are handled differently. The parameter code for using bind variables is in place, but so far I had little incentive to really implement it.

Since David Knight put the adaptor thru some tests, it became clear at which places the adaptor was still lacking. So I just want to list a few of the improvements, that have appeared.

  • stored procedure support with output parameters
  • describeResults implemented
  • all delegate messages implemented
  • error handling uses exceptions (not just NSLog :))
  • and of course various bugfixes

I would consider the adaptor to have reached beta stage. There are some known bugs and a few missing features, but nothing substantial is missing. Availability to the public is still a big unknown though

Now comes of course the big question ? How do you get the adaptor ? The answer mail me and we will see. Make me an offer I can't refuse. I am still not sure what to do with it. I am starting my own company in a few weeks and we will use the adaptor there. Maybe it will be a proprietary business model.. we will see.


This software is in no way fit for serious development or (shudder) even deployment. This is not alpha, this isn't even pre-alpha. These are some of the known problems of this technology demonstration

  • does not handle character encodings correctly, in fact it doesn't handle them at all
  • does not try hard to be compatible with the original SybaseEOAdaptor
  • should not be used together with the original SybaseEOAdaptor
  • is not a drop in replacement for the original SybaseEOAdaptor
  • has not been tested
  • does not implement all known Sybase datatypes (but all the major ones)
  • does not produce well defined errors/exceptions
  • probably has memory leaks
  • blob handling is really slow
  • can not create EOModel information from an existing database
  • does not produce SQL for primary key generation and constraints
  • dumps a LOT of debugging output
  • other versions than ASE11 have never been tried
  • never tested on DP4

Anyway Feedback is welcome and should be sent to


You need to download and install two packages. There is the package for the adaptor. You also need to download the FreeTDS Framework package to provide the ct_lib library. You can get the source for FreeTDS at The FreeTDS framework is missing some routines that the MulleSybaseEOAdaptor doesn't need currently (like f.e. the bulk stuff).
The adaptor is Copyright 2000 by Mulle kybernetiK. This current snapshot release is Freeware. The FreeTDS framework is LGPL.

Binary FTP MulleSybaseEOAdaptor.tgz
Binary FTP FreeTDS.tgz

Where is the source ?

This preview of the MulleSybaseEOAdaptor uses FreeTDS as a ct_lib replacement. FreeTDS is neither complete, nor bugfree. It also does not seem to be the very best implementation and has the general problem of being a LGPL product. Reading the license, I am of the opinion that my adaptor is not also automcatically subjugated under the LGPL, and your code that links to the adaptor and implicitly FreeTDS can therefore be as commercial and non-open source as you wish. But your lawyer's opinion might differ.

Licensewise I have three options:

  1. Go commercial, write my own CT/TDS replacement library (should be fairly simple) and sell the adaptor thru my company (non-Mulle). This has the following advantages
    1. since money is coming in, I can justify spending time on this project and also implement those features, that I do not care about, but you might.
    2. the adaptor is then a supported and a live product - with real support, not like Apple :) Might be a decisive factor, when trying to get a project with Sybase through executive layers. Or isn't it ? Tell me...
    3. giving the source with the code would be no problem (I guess).
    4. some real documentation
  2. Go Freeware/OpenSource via Mulle kybernetiK. One hopes that people will join your development effort, but from my experiences over the years - that is not gonna happen in reality. (Except from fellow Mulle kybernetiK coderz of course!)
    1. The supposed advantage for me is less work, the advantage for you is less pay. Also there are the synergistic effects with FreeTDS to consider.
  3. Combination of 1 & 2. the adaptor is freeware and open source. We sell support via company to get at least 1.a) and 1.b)down.

What's your opinion ? Mail me at