Showing posts with label Databases. Show all posts
Showing posts with label Databases. Show all posts

Monday, December 14, 2009

My Open Letter to the European Competition Commissioner

Monty urged me to help save MySQL. I couldn't possibly refuse such an offer.
Dear Competition Commissioner:

I am the Chief Executive and Technology Officer for OpenGamma, a financial technology startup located in the United Kingdom. I am writing to urge you to immediately and unconditionally approve the merger of Oracle and Sun.

I have a long standing history with both the Open Source and Database communities, having worked for a number of database startups in the United States of America, as well as working at early-stage companies making use and refining a number of Open Source technologies. I also have experience working at Oracle during a summer internship while I was attending the University of California at Berkeley.

Furthermore, in my more recent career as a consumer (rather than producer) of database technologies, I have setup and managed numerous, large MySQL installations, including one with more than 10 nodes and 150GB of active data (and several terabytes of archive data) in the financial services industry. I have also been a customer of Oracle's database technology for systems even larger.

In my mind, there is no logical reason to reject this merger based on considerations for the MySQL technology.

First of all, as a consumer of database technologies, I can tell you that Oracle and MySQL simply do not compete in the marketplace. While customers have replaced Oracle with MySQL, the applications based on Oracle that were ported to MySQL were never good candidates for Oracle and would have been ported to another database engine in due course as Oracle moves to the highest end of the market. Customers have numerous options for porting their applications off of Oracle onto a lower-cost database engine; MySQL simply has the most brand recognition in this space. Furthermore, MySQL has been used as a pricing lever by Oracle customers rather than an active option for migration.

That implies that Oracle's ownership of MySQL might see a reduction in competition for Oracle's core product, but there is a flourishing Open Source database market these days (which there wasn't when MySQL was originally created): Ingres, Firebird, LucidDB and PostgreSQL are all far more applicable to the Oracle customer base than MySQL is. Even if MySQL development were to come to an immediate halt, this wouldn't harm consumers in a such an extremely competitive environment.

However, the continued uncertainty over the Sun acquisition is potentially far more anticompetitive for consumers of technology as a whole: Sun has a number of competitive products with far greater applicability than MySQL (including their storage, networking, and computer chip technology). Allowing those products to die because Sun ran out of cash during this phase of its life would be extremely and permanently damaging to the overall computer industry inside Europe, and reduce competition significantly. Delaying this merger over the matter of MySQL would result in far greater anticompetitive results to European consumers of computing technology than even the worst case arguments of biased, self-interested advocates in this matter.

Thank you for your time, and once again, I urge you to approve this merger unconditionally and without further delay.

Sincerely Yours,

Kirk Wylie
Chief Executive Officer
OpenGamma

Thursday, December 10, 2009

Document Stores: Please Give Me A Standard API

Although I'm a long-standing RDBMS guy (having worked on Broadbase, Kidar, and Eigenbase/LucidDB [indirectly through Kidar and Broadbase]), I'm quite excited by the emerging document-oriented database movement. While I'm not a pure "SQL is bad and old-economy and you should throw it away" guy, I do think that document stores, like their Hierarchical Database precedents, have their uses in modern architectures. In particular, practical (as opposed to theoretical) aspects of the use of a hierarchical/document model allow for advanced scalability and performance optimizations to be made for modern scale-out architectures.

That being said, even though we're at early stages, I think the major proponents of the technique need to learn from the RDBMS guys in one important aspect: unified APIs are key to widescale adoption.

If I'm writing an application that's going to be backed by a relational database, if I'm in a sensible programming language, I've got a standard API that I can code against: JDBC, ODBC, ADO.NET, et. al. It doesn't shield me entirely from differences in the underlying database implementation (or else there would be no opportunities for product differentiation), but it makes those differences minimal and relatively easy for a software developer to abstract.

Ditto for message oriented middleware: I can use JMS at the code layer, or AMQP at the network layer (and thus at the code layer as well). While different MOM implementations have underlying differences, which are particularly obvious if I want to push the technology to its limits, the product-specific differences are noticeable in the breach rather than in the general.

This isn't the case right now for document stores. I know that MongoDB and Riak and CouchDB and SDB and others (which I'm sure commenters will point out below) are pretty darn similar in their functionality. I know that the conceptual models are relatively similar. I know this logically. But I still have to do custom code for each one for my own application.

With multiple implementations out there, and with users (e.g. me) looking at the different systems and seeing them logically similar, it appears that it's probably time for the teams to start working together and come up with a code-level API that I can code against, much like JDBC or JMS. While this might seem like early stages for such an effort, trust me, it'll greatly lead to increased adoption because the perceived costs of evaluating different implementations will be greatly reduced.

It doesn't mean that you can't differentiate; it doesn't mean that you can't be superior or inferior to other implementations. But it does mean that I, as a consumer of these systems, can more easily support multiple implementations. And if I can do that, I'm more likely to move to one in the first place.

Wednesday, October 28, 2009

Monty's Almost Certainly Looking For Investment

Remember how I predicted that Monty was attempting to create such an untenable situation for Oracle that they had to dispose of the MySQL IP and put it into his hands? Remember how all of Monty's protestations were based on the fact that he doesn't have the money to buy it? Remember how I said that he might not have it now, but could probably raise it?

Yeah. He's trying.

From Reuters, Florian Mueller is touring Wall Street:

EU strategist who is former MySQL shareholder and adviser announces Silicon Valley press conference (26 October) and New York City analyst briefing (27 October) -- Florian Mueller wants to "explain positions of critics of proposed transaction in the lion's den" -- New York event due to "strong Wall Street interest in the matter."

There haven't been any protestations from Wall Street that I've seen that they're unhappy with Oracle acquiring MySQL. Rather, this has been a European affair as Monty tries to get the EU to interfere in industrial policy for his own personal benefit. So why in the world would you send your sockpuppet to Wall Street to explain any positions? What interest would Wall Street have in the matter other than to provide funding?

You might argue that he's going there to talk about the position they're taking with the EU competition commission because there are lots of people who own Oracle and/or Sun stock, and might be interested in the matter. But I think a much simpler story is at least as likely: Florian is attempting to drum up a capital raise to acquire the MySQL IP to make the problem go away for Oracle, and to convince Oracle and Sun shareholders that Monty and Florian will do whatever it takes to block the acquisition so that they'll tell Larry to let go.

Add to the Look at the Balls on that Guy category: Florian Mueller.

Wednesday, October 21, 2009

Monty, Stallman, MySQL, Oracle, and Sun: Open Letter Wars

I've tried to confine my ranting about the current state of the Sun/Oracle/MySQL debates to my Twitter feed, but I think I need to do more than the 140 character limit allows.

Background On Recent Moves

In case you haven't been following the state of play, we've got two recent open letters sent to the EU competition commissioner: If you've been following either of my posts on the subject, you'll know I'm not a dispassionate observer in this matter, particularly where Mr. Widenius is involved.

Competition and Acquisition

First of all, let's directly address the core matter at hand, which is that Monty, RMS, and the various others appear to believe that the Database market is hopelessly consolidated and were Oracle to get its hands on the copyright to the MySQL source code that would be bad for competition.

This, to be honest, completely and utterly disregards the actual history of the database market, which has always been one of consolidation and benefits to the consumer:

  • Illustra, a Berkeley spin-out, was bought by Informix
  • Informix was bought by IBM
  • RedBrick was bought by IBM
  • RDB was bought by Oracle

While this consolidation has reduced the number of vendors in the market, as of 2007 there was still pretty hefty competition with Oracle even then only with a 44.1% share of the paid database market. As someone who has had to work professionally with Oracle, DB/2, Sybase, and Microsoft SQL/Server, I can say this is almost certainly because it's the best overall product.

Furthermore, those numbers in terms of the database revenue are completely suspect (with the exception of Microsoft's). There's a huge amount of revenue for IBM and Oracle which are tied to services and software sitting on top of the database (such as Oracle applications and IBM services), and realistically the CFOs of each company can tune the percentage of the deal that goes to the underlying database based on what numbers they want to report. The overall deal may be $1MM, but the sales person has a lot of discretion on how they price the database component.

Is there so little competition in the market that it's hurting consumers? Hardly. The recent squabble over Oracle's TPC-C pseudo-announcements indicates that the vendors actively compete with each other. Furthermore, the rate of feature expansion has been truly dramatic. Finally, the ability of firms like Vertica to rapidly jump into the market indicates that this isn't a market that requires significant levels of competitive concern on the part of regulators.

The technology industry is based on larger firms buying smaller ones. Competition authorities should rightfully be concerned only if it harms consumers in general, not whether it harms a particular subset of users.

But MySQL Is Special

With all due respect, no it isn't.

Let's consider the pseudo-market for Open Source databases. We've got:

And that's just considering the relational ones. When you consider the NoSQL movement as potential competitors (which I, for example, most certainly do), MySQL just isn't that special anymore.

While it is possible that an Oracle acquisition might be bad for MySQL consumers, it doesn't follow that MySQL is so special and perfect and pure that it harms any general category of consumers. While databases aren't perfectly replaceable, if someone found that Oracle's stewardship of MySQL was so onerous that they wanted to move off of it, it wouldn't be impossible to move to another database, either commercial or Open Source.

What that means is that you're in a classic case where the acquisition of a particular company might be harmful to consumers of that company's products, but it doesn't generically affect the market in a negative way. IBM and Microsoft will continue to compete in the commercial space, and PostgreSQL, Ingres, and LucidDB will continue to compete in the Open Source space. There's no net harm to consumers as a whole from an acquisition, even if the result of the acquisition was the complete shutdown of all commercial support for MySQL.

Oracle Is A Bad Acquirer

First of all, let's get the obvious out of the way: Oracle bought BerkeleyDB, and continued to enhance it; Oracle bought InnoDB, and continued to enhance it. At no point did they crush them to drive Oracle database revenues, or change the licenses, or stop forward momentum. So when you look at the actual track record of the company, they're in the clear.

But they might do, because they're an evil, scary corporation that MySQL turned down once before (from the Stallman piece):

Oracle made an earlier effort to buy MySQL in 2006, but the management rejected Oracle's offer, in part because Oracle would not disclose its plan for MySQL, and some members of the MySQL management team were concerned that Oracle was only acquiring MySQL to curb its advances in the marketplace.

I know a number of people involved with MySQL when it was an independent organization. While there were people who worried about that fact, senior management wasn't. More importantly, Monty was willing to sell MySQL to Oracle in 2006 for the right price. The use of the words "in part" there are telling, because the primary consideration that MySQL's senior management had wasn't some happy-clappy love for the Libre Software Movement, it was money.

I'm sorry, but I fail to see what's changed in between 2006 and 2009 except that Monty is a whole heck of a lot richer. Why in 2005 and 2006 were offers ultimately rejected from Oracle based primarily on money, but now Oracle is an evil corporation that can't be trusted with MySQL? Larry's the same guy he was then, Oracle has bought BEA but they don't compete in any way with MySQL, it's the same company. Why would Monty trust Oracle back in 2006 but not now?

Force Oracle to Sell MySQL

This is Monty's solution. And it's cunning. It's particularly cunning that he says repeatedly that the obvious Monty-connected acquirer, Monty Program AB, lacks the funds to do such a purchase. Again, a half-truth.

MySQL was worth $1Bn in early 2008. Since then markets globally have tanked, but MySQL has had some good commercial strength recently within the Sun organization. So let's conservatively say that it's still worth $1Bn. Let's then say that Oracle values the acquisition of Sun highly enough to let MySQL go for less, and do a 20% haircut to $800MM. Who's got that kind of money to acquire?

  • Microsoft. You think Stallman and Monty would be happy with that? No.
  • IBM. #2 in the database market. Erm, raises same issues that Oracle would.
  • Sybase has the market cap (super-recently) but not the cash.
  • Red Hat has the market cap, but not the cash.
  • Novell lacks the market cap and the cash.
  • Computer Associates has the market cap and the cash, but is the place technology goes to die. They also have Ingres to work with.
  • VMWare has the market cap and the cash and an acquisitive streak, but would MySQL really fit into their product strategy? I can see Spring driving people to vCloud, but can't even fathom the same kind of strategic benefit for MySQL.
  • Symantec has the market cap and the cash, but their storage work has been pretty solidly focused on backup and low-level storage these days.
It doesn't look to me like there are that many companies out there that could really buy MySQL in cash and make Stallman and Monty happy.

But you don't actually need to have the cash yourself: you can use private equity money. It's happened before: BEA was funded by private equity originally to consolidate the Tuxedo market. That's why Monty's protestations ring hollow: his statement is explicitly "we don't have the money." But I think he could probably come up with it, and if he doesn't, then he needs to work with better financiers.

Finally, let's assume that Oracle really wants the rest of Sun, and considers carefully Monty's open statement that Sun is hemorrhaging $100MM of cash per month. Wouldn't it make sense for Oracle to actually just donate MySQL to pretty much anybody to make the EU issue go away? Oh, and lo and behold, Monty has two of those ready to go: Monty Program AB, and the Open Database Alliance.

To me, the current situation amounts to blackmail: we'll keep blocking your acquisition of Sun until you do what we want.

Consider The Sources

So let's look at the motivations of the major current players.

Stallman is irrelevant to any commercial discussion. His press release essentially says "I don't like the GPLv2 anymore, even though I wrote it, and it would be better if MySQL was under the GPLv3." Tough. Furthermore, RMS has no commercial experience of any kind. I fail to see how someone who has never even worked for a profitable commercial enterprise could be considered knowledgeable about how an acquisition would affect the marketplace in an anti-competitive way that harms consumers.

Furthermore, RMS' press release completely belies his previous positions regarding the possibilities for commercialization of GPL projects. He's stated in the past that offering dual licensing is only one of many ways that you can make money with the GPL being the dominant licensing model. Why all of a sudden does he believe that this is the only possibility for MySQL? Why is he so adamant that without that ability, there's no ability to derive commercial revenue from MySQL?

Monty has been slinging FUD about this acquisition for months. He was such a disruptive element inside Sun that they released him from his Non-Compete just to make him go away. Given that he's an extremely rich, disgruntled ex-employee and project founder, he has personal reasons and financial ones (under the Monty Program AB umbrella) to cause as much disruption to this deal as possible.

I've said it before and I'll say it again: Monty has been playing a long game here, and I think he'll be obstructive to any potential move that Oracle would make with MySQL until the IP is under his control.

Personal Opinions Should Not Drive Competition Policy

Ultimately, you can sum up the entire argument against the Oracle/Sun acqusition due to the MySQL situation as:
  • We don't like Oracle owning the MySQL IP
  • Therefore, don't let Oracle own the MySQL IP
Unfortunately, saying that you personally dislike something doesn't provide a valid reason to block an acquisition on competition grounds. Saying that you don't trust Oracle doesn't alter the marketplace in a way that disadvantages customers as a whole. Saying that nobody else could make money by selling commercial licenses for MySQL doesn't mean someone else must be allowed to.

The moment the MySQL founders, who have been handsomely rewarded, took VC money they turned MySQL from being a hobby project/company, and into a major technology company and an asset. The change happened years ago, it's just that they're only starting to wise up now.

But it's happened. It's done. It's no longer anybody's pet project; it's an asset that can and should be used by whomever is willing to pay the most for the IP. As a customer, under the GPLv2, you still have rights, including the right to fork. But don't go whining that a company that made massive amounts of money for its shareholders by commercializing a technology is no longer under your control.

Wednesday, May 27, 2009

Monty Bites The Hand That Fed Him: Part 2

(Take a look at Part One of my Monty-Watch for some background as to what I think about the situation).

So Monty Widenius and Peter Zaitsev did an interview with Matthew Aslett on the creation of the Open Database Alliance. It's well worth a read.

For the record, I don't want anybody to conflate my opinions on what Monty's done with anybody else associated with the Open Database Alliance. I actually think that having such an organization ex-Oracle to make sure that there's a unified voice for everybody working (and attempting to make money) from the MySQL ecosystem, outside the current corporate owner of the MySQL brand, is a Good Thing (and something I think other projects with a single major corporate sponsor may lead to in the future). As such, having a place for all the various consultancies and technology providers to work together to ensure their interests are looked after is a pretty useful and innovative thing.

However, let's play "Look At The Balls On That Guy"!

Actual Quote Time:

I have, however, offered Oracle a partnership with Monty Program Ab, under which Oracle could get access to some of the critical developer resources Monty Program Ab has available. Monty Program Ab could also help Oracle with their open source strategy and serve as a ‘trust creating’ entity between Oracle and the open source developer community. Oracle has however not yet responded to this.

Kirk's Translation:

I have hired all of the people that ever worked for me when I stormed off from Sun in a huff. Now you may have the MySQL brand name and core IP, but I have all the engineers. Furthermore, I've been sowing as much FUD as I possibly can when, quite frankly, you haven't done anything directly to harm the interests of the MySQL community. If you want me to publicly step down from the FUD-slinging, I have a bank account to which you can send some [more] money.

Anyone who doubts the actual motivations of Monty's recent efforts should read the real quotation (as well as my translation). I think it speaks volumes about what he's attempting to achieve here, which is quite simply to spread enough FUD about Oracle's relationship to MySQL that Oracle feels like it has to engage in some type of action to bring Monty back into the fold in some form, which would involve some type of cash money payment. There really is no other conclusion possible for someone who says, in no uncertain terms: I have all the core developers; I've damaged your relationship with the core community; You could pay me and make the problems go away.

Friday, May 15, 2009

How Many Times Can Monty Sell MySQL?

UPDATE 2009-05-27: Monty's spoken to Matt Aslett, and I've responded.

COMMENTARY UPDATE 2009-05-27: If you're just reading this for the first time, after posting this it became clear (through back-channel to me) that Sun did have Monty under an Non-Compete, and chose to allow Monty to get out of it. I've commented about that in the comments [which you should really read] and in the Proggit thread. I still think Monty's actions are pretty bad looking even given that, but you should understand that there was a Non-Compete, and Monty was let out of it by Sun, before you read the original article below.

I've been thinking this since it was announced, but Monty's current attempt to monetize MySQL by hamstringing the eventual owner of his original attempt is really quite, ahem, ballsy. For a much less ranty analysis with quotes from M-Dawg himself, see Stephen O'Grady of RedMonk's writeup.

Let me give the Kirk "worked for 3 database companies and founded one expressly to compete with MySQL" Wylie synopsis:

  • Monty writes MySQL way back in the day, largely so that he has a database system which doesn't have any of the complex features of an RDBMS that make it work well (you know, referential integrity, transactions, views, proper metadata support).
  • People start using it, largely because it's Free-as-in-Beer (this was back in the days of minimum $100K Oracle buys just to run a simple web site), but also because it's easy to setup and administer (which Oracle/Sybase/SQLServer/DB2 were not).
  • Monty wants to get rich.
  • In an effort to get rich, he takes a boat load of VC funding to push MySQL from being a small open source collective to a Real Company.
  • VC funding requires a business model that has real revenue behind it.
  • Company adopts a split licensing model (which pissed off a lot of people at the time), and starts being effective in attracting revenue and very, very smart people as executives.
  • Monty's dreams of success are realized when Sun pays a king's ransom for MySQL.
  • Monty wants to have his cake [1] and eat it too, and gets all pissy and storms off in a strop and founds an attempt to get rich a second time on the same project.
  • Oracle buying Sun means people take this attempt even more seriously and he attracts people who never liked the post-VC-funding MySQL business model in the first place to the cause.

So here's the question that everybody should have on their minds: How many times will Monty attempt to get rich off the same project? [2]

Now I wasn't privy to any of the contractual arrangements around MySQL's incorporation, or his common stock stake, or the Sun buyout, or any of his employment agreements [3]. I will, however, postulate that if Monty doesn't have Fuck You money at this point given a $1Bn buyout of the firm he founded, he did something Seriously Wrong, and you probably shouldn't trust his business instincts.

So one of two things is going on here:

  • f(Cake + Eating) == Cake
  • He fundamentally doesn't agree with a split licensing model and thinks it's doomed to failure. I really hope this isn't the case, because if it is, he was acting disingenuously at best when working for the Original Monty MySQL-Based Get Rich Scheme, by supporting a model that he didn't believe in.

If it's the latter, why did he start down the path of taking VC money in the first place? Seriously, did he honestly believe that he could take a boat-load of risk capital, and not have to provide returns to the limited partners at the core of any risk capital facility? Did he lose some type of boardroom squabble over the direction of MySQL and has been nursing a grudge ever since? [4]

Here's something any founders of Open Source projects need to realize: VC money comes with strings attached; do not take that money if you don't want to take the strings. The strings are entirely financial: VC/risk capital requires a very hefty payout in a relatively short (5-10 years max) timeframe to the limited partners who provided the VC firm with its capital to invest. In order to ramp up revenues in a reasonable timeframe, you will need to have some facility to generate reproducible, cheap-to-deliver revenue in that timeframe. Open Core is one approach, Split Licensing is another, all manner of Services are a third, there are a whole host. But you have to come up with one. Otherwise there's no point in raising risk capital, which must have a hefty payout.

If you just want to have a lifestyle business (and many lifestyle businesses can, over time, still provide you with Fuck You money if you structure them properly), while constantly maintaining an environment where you can do what you want technically in a purely-Libre environment, don't take risk capital. Grow your business organically, and enjoy the life that you've created for yourself.

But the moment you accept that term sheet, you've crossed the barrier beyond a pure hacker coding for fun, and a company executive who must deliver returns to his investors (and that may require doing things that the hacker side of you finds distasteful). If you're not willing to sign up to the transition between pure Open Source techie and Business Executive, don't accept the term sheet. And for the love of the FSM's noodly appendage, don't accept the term sheet thinking that you're going to screw your investors in the long term by going back to your roots once you've got your payout. [5] Doing so screws it for the rest of us.

Here's the #1 problem Monty's move has caused for anyone attempting to make Fuck You money off Open Source: it should make VCs very nervous indeed about Open Source investments. Let's examine what I would consider to be a logical thought process:

  • If we invest in an Open Source company, the most likely outcome is an acquisition by another firm.
  • If founders of projects make it a habit of storming off to fork their invention because they don't like the monetization model they helped establish, other firms are very unlikely indeed to buy Open Source companies.
  • If other companies are unlikely to buy Open Source companies, our return on investment in them will be much lower.
  • Therefore, there's no point in looking at them.

None of this impacts Monty: he presumably already has his Fuck You money.

But if I were a VC looking to invest in an Open Source company, I would insist on an enforceable non-compete if I could [6], and I would make sure that my exits prevented the founders from being able to fork. Otherwise, my assets are really only there to make the founders enough money that they can pursue their dream of working on pure Open Source code with enough money that they no longer have to try to get rich. Which is great for them, but not for the rest of us who aren't rich but wish we were.

Remember: going for the brass ring and taking VC money requires that you compromise something. If you don't like it, don't take the money. But once you have, realize that you may need to walk away from your baby once you've got the money for the sake of everybody else.

Just as an aside, bear in mind that nothing should stop you from doing Open Source work, including starting an entirely new project on the same basic idea, once you have your payoff. It happens all the time in other industries (how many networking hardware companies have been founded by the exact same executives?). But resist the urge to fork your original project. It's unseemly at best, and flat-out unethical at worst. If Monty had started MariaDB from scratch, that would be one thing. But he didn't. And that's the thing that makes this all seem, well, just a little bit wrong to me.

Footnotes

[1]: By cake, I mean chedda/dead presidents/papa. Cash money, yo.
[2]: Clearly more than once.
[3]: Hence I am totally unqualified to comment here. I'm doing so anyway, because if you keep reading, this turns less Monty-directed and more general-parable.
[4]: There's a reason nobody ever saw the code for my Compete-with-MySQL Open Source Database startup.
[5]: I'm not actually accusing Monty of this, and nor do I believe it to be the case (believe it or not). I think there's something else going on here. But I could see that some people might think that unethically, and you really shouldn't.
[6]: Yes, there are ways to structure this, usually during the M&A stage, by having deferred payments to the founders which don't trigger if they fork for some period of time, that even comply with California and UK restraint-of-trade law.

Monday, April 27, 2009

Sybase JDBC Drivers Ignore Your Database Selection

A very common strategy in doing database-driven functional tests is for each user to have their own database instance on a shared test machine. This means that they can do whatever they want on that database instance without impacting other users, and that multiple people can run potentially destructive test cases simultaneously.

A common approach to handling that is to append the user name to the database name, and use a system property to choose the correct database instance for that test run (for example, naming your DataSource bean in your Spring context.xml something like db_${user.name}). You then have the JDBC connection declared to have the user name in the connection string (a la jdbc:foo:bar:blahblahblah/myapp_${user.name}). All works great.

Except with Sybase.

In its voyage of annoying developers who have to use their managed language drivers (the C#/ADO.Net ones are particularly noxious), Sybase have decided to screw you by ignoring this parameter when it's not valid.

The Sybase low-level protocol for this scenario largely consists of the following steps (completely simplified):

  1. Connect as user Foo
  2. Connection is now bound to the default database defined for user Foo
  3. Issue a use correct_database statement
  4. Connection is now bound to the database specified in step #3

Here's the problem: if step 3 fails because the database desired doesn't exist, Sybase will silently swallow the failure, and you'll end up in the default database for the user, and not tell you (seriously, there's no log or exception or absolutely any sign of what database you're in). Even better, the Sybase driver doesn't even store this in any field that you can introspect in the debugger, so the Sybase client library thinks it's in the database instance you want, when in fact it's not.

If you have a shared test database (with some real data in it for doing manual/gui-directed testing), and surrogate databases for each user's "blow-away-the-world" style testing, this is Very Bad Behavior Indeed.

Solution: Stop using Sybase. Seriously. Yes, it may have been en vogue 10 years ago, but it sucks.