Is there a framework or class that allows Cocoa and Objective-C to interface with a remote database, be it SQLite, MySQL, or another (though preferably SQLite)?
You can download the source and compile this yourself but I have read that it is a pain and I think the project may be dead:
CocoaMySQL-src
However, connecting to a remote DB directly from an iPhone/iPad App is a very bad idea. Imagine someone with a jailbroken iPhone and a simple packet sniffer.... It would be incredibly easy for someone to compromise the security of your Database.
The best way to acomplish this is to wrap it in php via a web server on your remote Database server. You can then run a query on the DB with a simple http POST request and have the page return xml/json/whatever.
Related
Awhile ago I was looking around for SQL connectivity with my embedded devices and people recommended not to use ODBC because it would not be able to maintain a constant connection if it were wifi etc. So they recommended I just connect using HTTP requests for data-entries etc. So is this possible and if so what do the requests typically look like?
Btw I would use SSL/TLS for encrypted connection because plaintext over the internet is a nono.
Also this would help because all I have learned was microsoft's ODBC library and I relied on it a lot because now I don't know how to connect to MySQL database from Linux as I have not seen a C++ odbc library, so learning the HTTP way would make it more universal.
We use a particular ODBC driver here to access a legacy database. Our homemade software (a 2 tier vb.net winform application that connects to an sql-server database) could really use it for some operations. Unfortunately, due to licencing restrictions we cannot deploy the ODBC driver on more than one computer. I'm looking for a way to go around that.
My initial thought was a WCF service and POCOs. However, since the app references a library with a rich set of generic ADO.NET helper functions, I really want to reuse these to communicate with the server. So I'm thinking of making my own ADO.NET implementation to access the WCF service that will, in turn, expose session objects to process queries sent by the client.
Anybody did something like this before? What challenges awaits with implementing my own ADO provider? Also, is there something like this that already exists, before I go and reinvent the wheel?
You can use an ODBC-ODBC Bridge to access you legacy ODBC driver from any other machine and still access it via ODBC. Sounds to me like this would be a lot less effort.
Update: I can only describe the Easysoft ODBC-ODBC Bridge as I've not seen the code of any other bridge. At the client end you install the OOB client ODBC driver. On the server end you install a service. The client end effectively sends your ODBC calls and data to the server where they are redirected to the actual ODBC driver you want to use. Of course, there are loads of optimisations performed both in the ODBC APIs and the protocol. There are a lot of advantages to this a) you can use a driver you cannot get for the platform you want to code on b) you can use a 32 bit application to talk to a 64 bit driver or vice versa c) you might only be able to or want to use one license for the driver/database on the server d) you can cross networks to access a remote driver etc.
Transactions are handled properly in the Easysoft OOB.
Many applications use the following model:
Browsers or other clients interact with application servers.
Application servers (web servers or RPC servers) interact with data store servers (SQL servers or non-SQL storage).
For internet applications, they need application servers because they must keep simple feature on data servers for performance. But I can't see why they need application servers on intranet.
For example, can we develop an Adobe AIR application, which directly connect to a PostgreSQL server? I guess we can deploy a center PostgreSQL server which has many stored procedures and set strict permission, and let the Adobe AIR application fetch (and modify) data only by invoking the stored procedure.
Why don't the most of applications choose a simplier solution?
In general, there is no reason why you couldn't get an independent application to talk to a PostgreSQL server directly. Some applications do this and it works fine.
I'm not familiar enough with Adobe AIR to say whether it's possible in this context. In principle, if you can get a PostgreSQL driver, or if you can write your own using TCP sockets (the PostgreSQL network protocol is documented in details in the official documentation), you could certainly connect directly.
This being said, having a form of application server between the end-client and the database server isn't purely for performance.
Web-based development allows the SQL queries to be controlled by the server. Instead of exposing complete SQL access, you expose the features that the client can use. If you need to tweak the queries later (bug, change of data structure, ...), you can do this rather centrally on your application server, without having the need to deploy a new version of the client to each user.
Of course, you can do some abstraction like this user server programming directly, but this isn't suitable for all applications. This may depend on what other features your application needs, for example if it needs to make use of a library programmed in another language. You can use some procedural languages bindings, but it's not always suitable: pl/Python is an "untrusted" language (which may cause security problems) and pl/Java needs a external add-on, for example.
In addition, not all applications are ultimately reserved for intranet usage nowadays. It often makes sense not to restrict yourself to intranet usage when you start designing an application.
I initially started with a direct access design and quickly found it useful to move to an application server where I talked to the DB via web services. Reasons included:
Handling DB restart, local connection loss, client IP address change, etc is much easier when you're talking to the DB over a stateless protocol like HTTP. This is more of an issue for remote workers.
Transactions are clearly demarcated and isolated in server-side transactional methods (I used EJB3 and container managed transactions)
It's much easier to add new clients like a phone app as they can share more of the code and business logic. Stored procedures in the database are very useful, but can be limited and occasionally frustrating.
Some tools/languages don't have built-in tools for talking to PostgreSQL directly, but can easily talk to a RESTful web service with XML or JSON request/response format.
DB admin is easier if you're dealing only with a single application server connection pool
The main downside is of course the extra layer means extra work and extra maintenance.
You can, but...
Browser languages/libraries tend to have poor database support
What happens when someone wants to use this application remotely?
If you're not talking about browser-based applications, then that is exactly what many do. There are plenty of traditional installed client applications talking to a backend database either directly or via a wrapper (odbc/jdbc).
Can someone point me to a tutorial or some resource that will show me how I can download or use a sql database from a web server and use that content in an app. I want to control content in an app dynamically, such that each time the app is launched, it loads content from the database and uses that to populate the app.
There are many ways to answer this question, but basically you should create a REST service (http://www.ibm.com/developerworks/java/tutorials/j-rest/) in the language of your choice.
This will connect to the SQL Server database.
Then you create a REST client in your program (consuming restful web service in iOS 5), and you can then interact with the database.
RestKit is an excellent library for build the iOS-side of a rest-driven system. Very actively supported, too. Has a nice tie-in for core data, too.
i need to build index server for p2p (games) application
can i just use web server(lighttpd) and extend it with some plug in?
is there any problem with this method?
Twisted is a framework for creating network applications. It's written in Python. You could use this to write your indexing server.
Not knowing any more about what kind of server you are wanting to write makes it impossible to say anything more, but it is unlikely that you can just extend an existing web server with some plugins.