FROM : Benjamin Einstein
DATE : Thu Jun 22 01:26:40 2006
Thanks very much for all the help. We've decided to run with MCPKit
for MySQL and distributed objects look like it'll fit the bill.
Does anyone outthere have experience with MCPKit (formerly known as
SMySQL)? I'm running into quite a strange problem. Connecting to the
database and running queries seems to work very well unless you want
to use a string created at runtime. Here's where we get stuck:
theResult = [theConnection queryString:(@"SELECT password FROM users
WHERE username = '%@'", username)];
Log window is spitting back:
2006-06-21 19:21:01.661 CIS[2650] Problem in queryString error code
is : 1, query is : username-
2006-06-21 19:21:01.661 CIS[2650] Error message is : You have an
error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near 'username' at
line 1
What's most obscure is that this works great:
theResult = [theConnection queryString:@"SELECT password FROM users
WHERE username = 'username'"];
Also tried a separate pointer to string in a previous statement, no
beans. Am I doing something flagrantly wrong? Are any SMySQL users
around?
Again, thanks for all the support so far, I've been finding my first
two weeks of Cocoa programming very exciting and surprisingly quick.
On Jun 20, 2006, at 12:44 PM, Keary Suska wrote:
> on 6/19/06 4:41 PM, <email_removed> purportedly said:
>
>> 1) Painless database connection. We'd love to use MySQL and it's
>> speed/price/scalability, but there seems to be no widely available
>> framework
>> for connecting to MySQL DBs from cocoa, except a product from
>> Serge Cohen,
>> which is undocumented/unexampled : http://mysql-
>> cocoa.sourceforge.net/.
>> WebObjects is too flimsy (as far as we can determine with mostly
>> web-based
>> apps). And our code, the way it currently stands using the MySQL C-
>> API, is
>> littered with more cString commands then I can stand. It requires
>> 3/4 full
>> lines of code to take the NSString from a text box and dump it
>> into a C-style
>> SQL statement. Our applications require a couple hundred SQL
>> skeletons; its a
>> pain. There HAS to be an easier way. Am I missing something basic?
>
> I wouldn't recommend MySQL. MySQL does *not* scale well and has
> poor data
> integrity enforcement. Also, the speed benefits of MySQL are
> significantly
> reduced if you require transaction support. For a mature, robust, and
> enterprise-quality RDBMS that is totally and *always* free (which
> MySQL
> isn't), I recommend PostgreSQL.
>
> There is no escaping C string conversion issues, since AFAIK there
> are no
> Cocoa-native API's. If you use a "wrapper" API (such as MySQL-
> Cocoa), the
> API likely hides this from you, but you may have to watch out for
> performance issues. NSStrings are huge and slow. In some test I
> have run
> with large data sets (10k or so), where about 2.5mb of raw data
> becomes
> about 30mb of memory as NSArrays of NSStrings. With large data
> sets, you may
> be better off keeping C strings until you need them as NSStrings.
>
> Fortunately, PostgreSQL supports prepared statements, which not
> only improve
> performance but enhance query re-use and resist SQL injection.
>
> The only significant drawback I find to PostgreSQL is that there is
> no way
> to determine the progress of a running query.
>
>> 2) Remote views. Another major feature that has us stumped:
>> building a
>> separate mini-application that allows users on a remote system to
>> fully
>> interact (in a controlled manner) with the primary interface.
>
> As suggested, you could develop a client-server system using
> distributed
> objects, which could be quite a task, or you could have a mini-app
> that
> interacts with the DB back-end. If you need a separate interface to be
> updated in a "live" manner--i.e. updated automatically every time a
> change
> is made--the latter option may pose some challenges. You could have
> the main
> interface "poll" for changes, for instance. If you were using
> PostgreSQL,
> you could use its asynchronous notification system to notify the
> "main"
> interface of changes and so to refresh its list.
>
> Hope this helps,
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/beinstein%
> 40comcast.net
>
> This email sent to <email_removed>
DATE : Thu Jun 22 01:26:40 2006
Thanks very much for all the help. We've decided to run with MCPKit
for MySQL and distributed objects look like it'll fit the bill.
Does anyone outthere have experience with MCPKit (formerly known as
SMySQL)? I'm running into quite a strange problem. Connecting to the
database and running queries seems to work very well unless you want
to use a string created at runtime. Here's where we get stuck:
theResult = [theConnection queryString:(@"SELECT password FROM users
WHERE username = '%@'", username)];
Log window is spitting back:
2006-06-21 19:21:01.661 CIS[2650] Problem in queryString error code
is : 1, query is : username-
2006-06-21 19:21:01.661 CIS[2650] Error message is : You have an
error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near 'username' at
line 1
What's most obscure is that this works great:
theResult = [theConnection queryString:@"SELECT password FROM users
WHERE username = 'username'"];
Also tried a separate pointer to string in a previous statement, no
beans. Am I doing something flagrantly wrong? Are any SMySQL users
around?
Again, thanks for all the support so far, I've been finding my first
two weeks of Cocoa programming very exciting and surprisingly quick.
On Jun 20, 2006, at 12:44 PM, Keary Suska wrote:
> on 6/19/06 4:41 PM, <email_removed> purportedly said:
>
>> 1) Painless database connection. We'd love to use MySQL and it's
>> speed/price/scalability, but there seems to be no widely available
>> framework
>> for connecting to MySQL DBs from cocoa, except a product from
>> Serge Cohen,
>> which is undocumented/unexampled : http://mysql-
>> cocoa.sourceforge.net/.
>> WebObjects is too flimsy (as far as we can determine with mostly
>> web-based
>> apps). And our code, the way it currently stands using the MySQL C-
>> API, is
>> littered with more cString commands then I can stand. It requires
>> 3/4 full
>> lines of code to take the NSString from a text box and dump it
>> into a C-style
>> SQL statement. Our applications require a couple hundred SQL
>> skeletons; its a
>> pain. There HAS to be an easier way. Am I missing something basic?
>
> I wouldn't recommend MySQL. MySQL does *not* scale well and has
> poor data
> integrity enforcement. Also, the speed benefits of MySQL are
> significantly
> reduced if you require transaction support. For a mature, robust, and
> enterprise-quality RDBMS that is totally and *always* free (which
> MySQL
> isn't), I recommend PostgreSQL.
>
> There is no escaping C string conversion issues, since AFAIK there
> are no
> Cocoa-native API's. If you use a "wrapper" API (such as MySQL-
> Cocoa), the
> API likely hides this from you, but you may have to watch out for
> performance issues. NSStrings are huge and slow. In some test I
> have run
> with large data sets (10k or so), where about 2.5mb of raw data
> becomes
> about 30mb of memory as NSArrays of NSStrings. With large data
> sets, you may
> be better off keeping C strings until you need them as NSStrings.
>
> Fortunately, PostgreSQL supports prepared statements, which not
> only improve
> performance but enhance query re-use and resist SQL injection.
>
> The only significant drawback I find to PostgreSQL is that there is
> no way
> to determine the progress of a running query.
>
>> 2) Remote views. Another major feature that has us stumped:
>> building a
>> separate mini-application that allows users on a remote system to
>> fully
>> interact (in a controlled manner) with the primary interface.
>
> As suggested, you could develop a client-server system using
> distributed
> objects, which could be quite a task, or you could have a mini-app
> that
> interacts with the DB back-end. If you need a separate interface to be
> updated in a "live" manner--i.e. updated automatically every time a
> change
> is made--the latter option may pose some challenges. You could have
> the main
> interface "poll" for changes, for instance. If you were using
> PostgreSQL,
> you could use its asynchronous notification system to notify the
> "main"
> interface of changes and so to refresh its list.
>
> Hope this helps,
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/beinstein%
> 40comcast.net
>
> This email sent to <email_removed>
| Related mails | Author | Date |
|---|---|---|
| beinstein | Jun 20, 00:41 | |
| Yorh | Jun 20, 01:24 | |
| colela | Jun 20, 01:38 | |
| James Bucanek | Jun 20, 02:24 | |
| Paul Lynch | Jun 20, 18:39 | |
| Keary Suska | Jun 20, 18:44 | |
| Benjamin Einstein | Jun 22, 01:26 | |
| Ryan Britton | Jun 22, 01:39 | |
| Benjamin Einstein | Jun 22, 01:45 | |
| Shaun Wexler | Jun 22, 02:15 | |
| Benjamin Einstein | Jul 2, 18:17 | |
| Bill Bumgarner | Jul 2, 19:03 | |
| Paul Collins | Jul 2, 20:25 | |
| Benjamin Einstein | Jul 2, 20:33 |






Cocoa mail archive

