|
I'm trying to deploy a simple PowerBuilder app using a SQL Anywhere 11 database and the SQLA run-time engine. I have all of the SQLA DLLs deployed that are documented and I can start the database engine when I create an ODBC entry. However, I get a syntax error on a simple select. Of course, running on my development machine does not product this error. Any ideas what's going on? Am I missing a DLL? I've tried the syntax both with quotes and without quotes. Deployed Files:
|
|
Jason, OPTIONS is a reserved word, so when you use it in a SQL statement, it must be double-quoted. For example, issuing this statement: SELECT * FROM OPTIONS; will return the syntax error you saw. But if you use this one: SELECT * FROM "options"; then you get the desired result set. As an aside, I'd recommend that you do not use reserved keywords as identifiers. You can get a full list of these keywords here: http://dcx.sybase.com/1101en/dbreference_en11/alhakeywords.html. José Comment Text Removed
I forgot to mention, I think you'll need the PowerScript escape sequence for double-quotes: ~" I'll try changing the table and column names. However, you can see above that I did use double quotes. And this syntax came from a DataWindow, which should take care of escaping quotes as needed. I dunno... we'll see if changing the table name fixes it. System Options ErrorSELECT "appoptions"."appoptionid", "appoptions"."appoptionname", "appoptions"."appoptionvalue" FROM "appoptions" Select Error: SQLSTATE = 37000 [Sybase][ODBC Driver][SQL Anywhere]Syntax error near 'appoptionid' on line 1OKcopying the database back to my dev and running the exact same statement (quotes and all) through isql works without an error. |
There is nothing wrong with the syntax that I can see... and I did test it using dbisql. It is complaining about "optionid" and if it was a reserved word problem it would complain about "options"... and you've double-quoted it anyway. When you take off the double quotes, what message do you get? What produces the error message? the format is new to me, as is the SQLSTATE value it's displaying for that message text. You may be right looking for a configuration problem, but I am very doubtful that such a basic flaw would be present in any copy of the engine... could be wrong there, of course.
Is the deployed *.db identical to the one that works OK on your development machine? Are there any views and/or triggers involved? Have you waved a dead chicken over the deployment machine?
oops, I didn't scroll down to read the comments on Jose's answer. If you want, you can send me a deployment package to test. Could it be something to do with the pbodb ini thing?