I’m able to connect to IMS segments and do sql queries with primary key in where clause and select * queries. But whenever I’m trying to do a select with another column I get a lexical error.
Select * from table where column-name='something'
This would give me the exception ‘Exception in thread “main” com.ibm.ims.jdbc.TokenMgrError: Lexical error at line 1, column 42. Encountered: “-” (45), after : “”‘. If I have the column name as first-name, then the lexical error would occur at position of hyphen in first-name. I’ve tried doing this via Prepared Statement and it still does not work.
After doing the following changes, I still get exceptions.
Select * from table where ‘column-name’=’something’
Caused by: com.ibm.ims.jdbc.ParseException: Encountered ” “\’column-name\’ “” at line 1, column 36.
Was expecting one of:
…
“(” ...
Select * from table where column+’-‘+name=’something’
Exception of lexical error with ‘-‘
Invalid escape sequence (valid ones are \b \t \n \f \r \” \’ \ ), this is the message I get when I’m trying for adding backticks or some escape sequences.
In most dialects of SQL the
-character is not a legal character in an (undelimited) identifier. For example, the SQL-92 spec says:(TL;DR – letters, digits and underscores)
(I hesitate to say all dialects, because the SQL language bestiary is rife with deviations from the various standards.)
First, the reference you found applies to escaping in string literals, not in identifier names. It does not apply to THIS problem. (And does it apply to your SQL dialect?)
Second, according to the syntax above, underscores should be allowed in identifiers … if the SQL dialect you are using is following the standard.
Third, the standard talks about “delimited identifiers” (using double quote characters as the delimiter). I don’t know how widely supported this is in real SQL dialects, but I imagine that even when it is there are restrictions on what characters you can use … and other caveats.
Fourthly, irrespective of what the SQL standards say, the documented syntax for the particular dialect you are using is what you should be looking at. (I was only using it to illustrate the general properties of SQL … in the absence of any details of the dialect you are actually using. “Mainframe” SQL could be many things.)
Finally, you will be better off not trying to use “funky characters” in identifiers. Use Latin letters, digits and underscores … and if your SQL dialect doesn’t even allow that, then stick to what it does allow.
And read the vendor SQL documentation!!!
Well read the vendor SQL documentation carefully. It should tell you what will work. And if it says the you can’t do it … well, you can’t.