I am trying to figure out how to utilize exisiting SQL Databases with my iPhone apps.
What i am trying to do, is have a search function. The user inputs a keyword, i would then query my SQL database dependant on the user input and return the results from a database.
How do i do this with the iPhone?
EDIT: I mean SQL Server 2005/2008 databases which are hosted online (remote).
Thanks,
-Mike
You need to write a PROXY PROGRAM to do that. You can't connect directly to SQLServer from iOS.
By proxy I mean a program using some kind of server side technology (IIS, ASP.NET, Java, C#) to connect to SQLServer, and implementing a TCP/IP based protocol (could be HTTP also).
On the iOS side, you need a TCP/IP (or HTTP) client to perform requests to the PROXY PROGRAM. Those request will have the SQL query you want to do in some form of internal encoding you can invent. When PROXY PROGRAM receives a request, it process the SQL query and returns and send results based, again, encoded in some form iOS could decode and process the information.
You should give iSql SDK a try.
Related
Is it possible to access Sql Server instance from Crossrider?
It has doc for local db and i am assuming that is used to store data on the browser's machine.
I have central data that gets constantly updated/read by plugin users and need a way to access external db (preferrably Sql Server but i am flexible).
Thanks
Crossrider does not provide a native way to interact with SQL servers (or any other external database), and you are correct about our local db support.
However, if you have the HTTP URLs for accessing your db, you can use the appAPI.request.get and appAPI.request.post methods to interact with your database.
My app reads data from two sources, a local sqlite file and a remote server which is a clone of the local db but with lots of pictures. I do not write to the server database, but I do need multiple simultaneous fetch operations.
What DBMS should I use for storing information on the server?
It needs to be very easily used from an iPhone app, be reliable, etc.
Talking to a remote server should not be tied to any platform like iOS. If you have control over the remote db server, the best bet IMO is crafting a RESTful API which you express your queries in, the server processes it and sends you the pictures/records using proper content type. If you do NOT have such control over the remote db, you'll have to stick to the API the db hoster provides. There are plenty such "on the cloud" db hosters (including NoSQL solutions) that give you a web-services interface to your db. MongoLabs is one such provider for MongoDB(which is a NOSQL db - meaning no schemas, no bounds on the structure of a "table"). You can continue to stick to SQLite on the client side.
You seem to have two sources of data local storage and a remote server.
This question on SO might help you to decide approaches of storing data on the server.
Once you have downloaded data using something like NSURLConnection class the images could be stored in the filesystem using writeToFile or the likes.
- (BOOL)writeToFile:(NSString *)path atomically:(BOOL)flag method.
You might like to save the rest of the data in sqlite. We used sqlite and the CoreData framework to save data for one of our applications and it worked fine for us. CoreData allowed us to interact with the database without actual SQL queries.
The iPhone client resides on the phone while on the server side we might have a database and a webservice interacting with the db. Webservice itself might be implemented in python or php like scripting language. The client interacts with the webservice that might return data in formats like XML or JSON. Thus there is no direct communication between the client and db. However, the client does implement network communication code to communicate with the webservice.
This page shows how to consume an XML based web service.
S3 allows you to post directly from browser to S3 bypassing your webserver (http://doc.s3.amazonaws.com/proposals/post.html). How can I upload files to a database in a similar fashion. I don't want to first stage the file in the webserver in a temporary file and then upload from there to the database. Thanks.
If I cannot avoid the webserver, then how do I just use the webserver for streaming and not actually land the file in the webserver before loading to the database.
Thanks.
A handful of DBMSes provide an HTTP connection design, but this is more the exception, not the rule.
That said, you can make the HTTP server a thin layer over a more traditional database, but this is probably a bad idea, because most databases assume that anything that can access them has full privilege to execute queries on them, and an application (read "web server") will act as a gatekeeper between the database and obnoxious or malicious clients.
Basically, You're going to do best using a database engine that does all of these things at a fine grained level, expressly designed for it. MongoDB mostly addresses this exact use case. Otherwise, you'll just have to write an application that sits between HTTP and the raw database connection.
How do I go about doing this?
You shouldn't.
Instead, you should make a web service that securely exposes the data you need.
(Do not write an ExecuteSQL method!)
If you really want to connect directly to SQL Server from an iPhone, you'll need to write a TDS client; it will involve a lot of work.
By exposing the data through a web service, you add a layer of abstraction between the database and the client app, allowing you to change the database without breaking the app.
Also, exposing SQL Server directly to the internet is never a good idea.
Finally, remember that port 1433 might be blocked at a firewall.
I've been talking with someone about the possibility of a iPhone development contract gig. All I really know at this point is that there is a company that wants to make an iPhone app that will hit their internal database. I'm not sure what the database type is( Oracle, MySQL, etc...).
I've wanted to know if the database type was Oracle or MySQL if there is a big learning curve for connecting to one of these across the internet?
If it's a real pain I may do more research before accepting the conract.
I would advise against directly accessing the database from the iPhone application.
Usually, you would create a web service which accesses the database, and then you consume that web service from the iPhone application.
Create a web service. This allows you to make the iphone app more of a thin client. Let the application push commands to the web service for processing and interaction with the database returning only the data needed by the app.
This option is better for the app, the database, and the customer's security.
You can easily perform the connection over the internet, the same way you would locally, but you are opening the database up to attacks if it will accept communication from any remote IP address. Typically you will just connect via a socket open to the server's remote IP address over the open port, MySQL's default port is 3306.
I would recommend against this sort of system in general unless there is some critical reason they want their internal database exposed to the world's hacker community.
What I am doing is creating a web service using Sinatra to access the online database.
Those answers from 2009 are mostly obsolete now.
http://ODBCrouter.com/ipad (new) has XCode client-side ODBC libraries, header files and multi-threaded Objective C objects that let your apps send SQL to server-side ODBC drivers and get back binary results! This reduces the need to stop and separately maintain SOAP/REST servers that can get pretty frightening anyway after a while maintaining it.
The XML schemes were okay for transferring static configurations to mobile devices "every once in a while", but XML was meant for infrequent inter-company type transfers in a "server environment" (with power cords, wired networks and air conditioning) and is definitely not efficient for frequent database queries coming in from n-copies of a mobile app. There are third-party JSON libraries that help things, but even with JSON, everything has to be encoded (and decoded) from the binary representation in the database to text representation on the server (only fine if it's going to be shown to the user in a web browser anyway, but not fine if the mobile app is going to translate it right back into binary so that it can perform calculations "behind the scenes" to what is going on with the user). Aside from the higher network overhead and battery power the mobile CPU will draw with XML and JSON, it will also make you buy more RAM and CPU power on the back-end server faster than just using an ODBC connection to the database.