Re: MSSQL
Re: MSSQL
- Subject: Re: MSSQL
- From: Andrew Satori <email@hidden>
- Date: Mon, 5 Feb 2007 21:22:15 -0500
You have several options, and I would vary my recommendations heavily
based upon your needs, as they all have quirks.
JDBC is certainly option, but with the official support of the Java
bridge going away, I would expect that any application that adopts
this method will require some complex workarounds in the future. The
advantage is that it is well documented, and of all of the methods
currently available on the Mac, it is the only one that has any
official status with Microsoft, in that they provide a JDBC driver
implementation.
Another choice would be to implement your MSSQL layer as a web
service using either C# with ADO.NET on Windows or Java and JDBC on
OS X and then consume the web services from Cocoa. This method is
slower, but far more ready for WAN or extranet usage.
There is also a raw C API library that comes with a full compliment
of command line tools, including the isql and bcp implementations
that will be familiar to most old school MSSQL users. This API is be
far the fastest library for accessing MSSQL data, but the API is not
very 'Cocoa' and can be a little tricky to consume.
There is also the lower level C and C++ API's for ODBC. I see that
both Jonathan and Ted have posted about ODBC, and as the maintainer /
instigator of the ODBCKit, which is as far as I know, the most mature
Objective C framework for ODBC currently available, I may appear to
have a bias, but...
This is where the, how and why become important. I work in a shop
that is MSSQL for all of the current offerings (as a matter of fact
I'm the only Mac user / programmer in the office). We are making
most of our code work against PostgreSQL as well for the future.
This is where the issue gets a little sticky. ODBCKit was born out
of my own desire to have a single framework to program against that I
could use against either server by switching DSN's. I've done
performance analysis, and using libfreetds (the open source MSSQL
client library), and libpq (the PostgreSQL client library) are both
faster than ODBC by about 5-10% depending upon the operations.
Because of that, I still use the lower level libraries for some
tasks, the most notable being bulk imports (and by bulk, I mean in
excess of 100k records at a time). But for user space applications,
ODBC is more than adequate, and with the async support that I'm
slowly enhancing within the ODBCKit, generally not a noticeable
limitation.
So, yes, I think ODBC is a good answer for 90% of the applications.
Unfortunately, asking about an MS product on this list is likely to
get you more than a few jeers, do yourself a favor and ignore them.
In order for Mac's to gain acceptance in the business world, we are
going to have to embrace MSSQL and to a lesser degree, MS Access as
servers until we can get OS X Servers running PostgreSQL in place to
replace them.
If you look at the ODBCKit pages, I am trying to create an
environment that is both Cocoa friendly and approachable for those of
us that are coming from a Windows ADO (ODBC, RDO, BDE, etc) business
development background. The current revisions of the ODBCKit sport a
basic but usable Query Tool for running adhoc queries. It also
contains a couple of Automator actions for automation of repetitive
data tasks. There should be samples for everything, but if you have
questions, feel free to ask.
Both Jonathan and Ted work for companies that provide excellent ODBC
drivers, and I think you should evaluate both carefully. I would say
that the curreny OpenLink offerings offer superior performance, but
require a little more understanding of the underpinnings to get the
properly installed, configured and optimized. The Actual
Technologies offerings are the easiest to install, configure and
tweak, but do take a VERY slight performance hit in comparison to the
OpenLink drivers.
There are also Open Source drivers as part of the FreeTDS toolchain
for MSSQL, they work, but you will have to be or become comfortable
with manual configuration of the various config files to make them work.
Now, one final item for thought. The most compelling reason for ODBC
for a developer is the ability to develop against local copies of the
data in PostgreSQL, MySQL (not really a good choice if you're target
it MSSQL), or even Sybase ASE, and then test and deploy against MSSQL
often with nothing more than a change of DSN, or if you need to deal
with some of the high end features of MSSQL, to use conditionals to
switch the SQL dialect as required.
As to ODBCKit, at the moment, I am the only contributor, however, I
use the product of the project every single day, so I'm constantly
fiddling with it, and it is growing into a major part of my work, so
I don't see it going away anytime soon.
Good luck and if you have questions, feel free to ask.
Andy Satori
Linky linky action:
My Blog About ODBCKit: http://web.mac.com/dru_satori/iWeb/Words of%
20a Geek/ODBC/ODBC.html
SourceForge Project for ODBCKit: http://sourceforge.net/projects/odbckit
OpenLinkSW (iODBC author and maintainer): http://www.openlinksw.com/
ActualTechnologies (drivers): http://www.actualtechnologies.com/
FreeTDS Project (MSSQL Client Libraries): http://www.freetds.org/
On Feb 5, 2007, at 5:12 AM, Benjamin Gereon Bailey wrote:
Hi,
Where do i start if i want to Write a client for an MSSQL database
in Cocoa ?
Thanks
ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >MSSQL (From: Benjamin Gereon Bailey <email@hidden>) |