Web Development

Interfacing with Microsoft SQL Server from OSX

Just last year I got my first Macbook Pro for development, after a lifetime of Windows (and linux/unix on server environments). I was very excited to get my environment set up as many friends who work in a similar field had sworn by it. I knew that almost every element of my workspace would be easily transferrable to OSX, and in some cases more elegantly. Technologies such as Apache, PHP, ssh/shell, etc are almost more native to the *nix core than they are to windows.

There was however a single piece of the puzzle that I knew I still had to deal with. Microsoft SQL Server. My work use it, personally I woudln’t choose it for my own projects at all, I’d choose something less platform dependent. Having said that I actually don’t mind the product OTHER than it’s requirement to be run on Windows. It is a decent product, it’s professionally supported, and most of the clients in my industry use it. In fact not so long ago some may argue that it was one of the best choices for large systems. It was FAR superior to the well known MySQL and a lot more affordable than Oracle. Let’s not forget it was originally bought from Sybase (which is probably why the product isn’t all that bad! Microsoft didn’t create it!)

So basically I needed to use MS SQL Server. I have a seperate windows box with an SQL Server instance on it, and what I needed was a client program that could connect to the server so I could query it, write SQL, interrogate data etc. I needed the equivalent of Microsofts SQL Management Studio (which used to be called “Query Analyzer”), or “MySQL Workbench“.

One option of course was to install VMWare, install Windows, install Microsoft SQL Server and just use Microsofts native client. But I really didn’t want to do that. So after much reading & researching I narrowed my options down to a few potential candidates:

So I tried all these products, and here’s the problem. They’re ugly. They’re clunky, awkward and … ugly. Most likely because they’re Java based – but they’re just hideous. When you get used to an environment like MS SQL Server, you just can’t revert back to this kind of rubbish. It’s funny you know, when you research this stuff, you see a lot of people recommending these products. And after using them you immediately realise that these people either a) come from an old school linux or java background where everything is ugly and they’re used to it, b) they’ve never worked with large or complicated datasets where EFFICIENCY is of utmost importance and probably consider phpMyAdmin suitable for data wrangling.

But the problem is they’re not ok. I’m sorry, they’re just not. They’re unpolished. There are real annoyances – the forms are hideous. The result set grids will have 10px padding so you can only see about 5 rows of result sets, or the result set grids cells don’t automatically resize to the width of the content within the cell (within reason) – they just don’t cut it. It’s situations like this when you realise the word ‘enterprise’ actually does have a meaning beyond just being a buzzword!

I was about to lose hope then all of a sudden, another contender crossed my path:

It was beautiful – I was in love. It’s a completely professional, sexy, clean, efficient, enterprise grade, high end. powerful SQL interface. It’s actually quite close to Microsoft’s native client in feel. I got it all hooked up, everything was working well, I even connected over mmy SSH tunnels to remote clients (an article on that later). It was all looking good until I ran into a problem. Running some stored procedures gave an error.

It turns out that SQL Developer is fine with standard SQL like SELECT, INSERT, UPDATE, DELETE etc, but when running certain SQL Server specific commands, SQL Developer doesn’t know how to interpret it, or interprets it correctly. A common problem seems to be the BEGIN and END keywords.  It also can’t handle multiple resultsets returned from a stored procedure, and won’t handle the “go” command in SQL Server scripts.

So unfortunately in the end I installed Windows XP (for it’s light weight), MS SQL Server and just use the native Microsoft SQL Management Studio. Given that my brand new Macbook Pro handles this without struggling it’s actually a fairly reasonable solution, but I cross my fingers that one day Oracle SQL Developer is completely compatible, or that someone makes a worthwhile GUI.

It’s worth mentioning that if you do fairly straight forward queries without very large datasets or without complex SQL, some of the above products may well be suitable for you, I’m happy to answer any questions you may have in the comments.

Edit (6th Jan 2015): It looks like some developers by the name of Hankinsoft ran into the same issue as many of us and have actually gone ahead and developed an MS SQL Client for Mac to address this very issue. The product is called SQLPro for MSSQL and although I’ve only recently started using it, I have to say so far it’s very impressive. It’s polished and pleasing-to-the-eye with it’s native Mac App design & feel, but at the same time is fast, responsive, efficient and dedicated to the task. It’s described as ‘lightweight’ and that’s what I love about it – so far, it’s handled everything I’ve thrown at it (including cross database joins etc), but isn’t overloaded with unnecessary features/preferences/bloating. So far I definitely recommend it.

9 thoughts on “Interfacing with Microsoft SQL Server from OSX

  1. And I thought it was only me that found these clients to be horribly designed. DBVisualizer is the best that I’ve found, but the free version has a few restrictions that make it less than ideal for even limited uses.

    1. Oh yeah, good point. I actually did come across DBVisualizer at the time I was researching options but gave it a miss cause the price tag seemed a bit high. Looking at the screenshots and functionality it does look very promising. I might give the free version a go just to get a feel for it first. Even though it’s not cheap I’m not adverse to spending good money on a product if it does the job well. Thanks for the tip!

  2. I had the same problem when I switched to MAC 6 months ago. I checked out a lot of options and ending up bying Navicat which is really really good. I was used to working on MS SQL’s own client.

  3. I encountered the same need. As much as the sticker price shocks me, I think I am also going to end up paying for Navicat. I’ve been using it’s 30 day trial and it’s by far the best tool available for SQL Server on Mac. DBVisualizer wasn’t able to show my stored procedures, and in general the UI for Navicat is better anyway, so I think the higher price is justified.

  4. Just FYI, GO is not part of Transact SQL, it’s the batch separator as configured in Tools->Options->Query Execution

    There might be an equivalent for the Oracle tool… if so it’s probably ; or something else similar.

    1. Yep you’re totally right. But at my workplace, the scripts I’ve inherited (of which there are numerous) are all in version control and have ‘go’ scattered liberally throughout. It’s used for batch separation in particular for when the scripts are passed through the linux ‘sqsh’ client. So it’s not something I can change unfortunately. That’s one of the reasons I can’t use the oracle solution.

Leave a Reply

Your email address will not be published. Required fields are marked *