OS X has libsqlite3 built in. You just have to include the header file
and link to the library. It's C based and you can write an Objective-C
wrapper functions around it. There are already some good ones like
FMDatabase or Quicklite.
Devon
dreamcat7 wrote:
Hi,
As a developer I aswell am finding it hard to evaluate these options
myself and without prior experience. For example I would be drawn to the
prospect of learning the same api for both the local and remote
database. (typically id like to cache the data downloaded from the data
onto a local sqlite DB). I did find only one ODBC driver for sqlite
http://www.ch-werner.de/sqliteodbc/
Which assuming (enough of it) should work would your comments still
hold? It is was the only Sqlite ODBC driver i could find so i am
inevitably wondering if thats a bad sign to use ODBC actually as an
SQLite interface. And actually how big an advantage would it be to learn
things the first time as the ODBC way only? (rather than starting with
the SQLite C api which is what others on this list have recommended).
And, apologies if this is heading off - topic but
My other option up to now is to use a special cocoa library for the
SQLite, and something rather different (MYSQL+PHP) on the server side.
This is probably a common question: It actually simpler then to go MYSQL
-> ODBC -> PHP rather than MYSQL -> PHP for such the benefit of doing
"everything" in ODBC.
If i understand from your comments then using this API will conceal
differences between MYSQL and SQLite and help me to concentrate on
learning a simple generic SQL syntax. But bearing in mind the
server-side code cant be written in Cocoa (objective-c) and in my own
circumstance it will be inevitably written in PHP. Do we really end up
with a more coherent environment (fewer languages) to work on our data
model which likely must be transactional with the client ?
On 17 Sep 2008, at 16:26, Ted Thibodeau Jr. wrote:
Can anyone suggest a multi Database library for use in developing a
Cocoa based app? At least support for Oracle, MySQL and PostgreSQL
would be required.
I notice that Python has good database support. Would developing a
PyObjC app be a better way to go?
ODBC... If you're working with any C-based tools, that is. Perl,
Python, Ruby, PHP, etc. -- they all have ODBC libraries.
JDBC, if you're working with Java-based.
Use ODBC/JDBC and SQL standards-compliant calls -- avoid DBMS-specific
dialect -- and you should find that things go pretty well. Changing
DBMS is in all these cases just a matter of changing the ODBC DSN or
JDBC URL -- and of course, having the relevant driver in place.
For full Cocoa ODBC support, you'll need to either build from source
or download a pre-compiled set of the iODBC Frameworks, as Apple has
chosen to only ship the dylibs. < http://sf.net/projects/iodbc>,
<http://iodbc.org/>, or
<http://download.openlinksw.com/download/product_matrix.vsp?p=f_db&fm=1&fam=7&of=5>.
I will observe that free drivers are often worth what you pay for
them, with incomplete and/or imperfect implementations of some API
calls, but there are plenty of options out there.
(I work for one driver vendor, OpenLink Software, which also happens
to be the maintainer/supporter of the open source iODBC Project, which
is the basis of the ODBC libraries on Mac OS X. We don't make any
money until/unless someone chooses to buy one of our drivers -- the
iODBC SDK is free in all ways, and all our drivers and other commercial
products have free download and 14-day (renewable) testing licenses,
and free up-and-running support; upgrading to permanent license only
requires a new license file. )
Be seeing you,
Ted
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please 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:
http://lists.apple.com/mailman/options/cocoa-dev/dreamcat7%40googlemail.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please 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:
http://lists.apple.com/mailman/options/cocoa-dev/dferns%40devonferns.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
