in reply to DBI not letting bind varibles in if you use a varible for the statement.

I'm looking at your code and I can only see one problem: you didn't post the code causing the error. I don't think jeffa's suggestion about using single instead of double quotes is relevant (sorry jeffa) as I use both single and double quotes all the time, depending upon the situation.

I would suggest posting the actual code snippet causing the error. Also, print out your SQL statement to verify that you have the syntax correct. However, make sure you get down to the bottom of this rather than just go the second route. I build SQL statements on the fly all the time and if I was forced to use your second example, I couldn't do that.

Random thoughts: your SQL statement was all caps. Is it that was in your program also? If so, are you getting some weird problem with field names being case-sensitive (I don't think that's it as that generates and "invalid field" message or something similar). Also, are you working with multiple fields and perhaps have your commas wrong?

Cheers,
Ovid

Update: I am totally stumped as to why single quotes would work here (as opposed to double quotes). The only things I could think could cause issues would be if you were to have unusual characters in field name (such as $, \, or @) which could cause interpolation within double quotes. Both with MySQL and MS SQL Server I've had no problem using double quotes.

Oracle's fields names are not case-sensitive? I suppose that's what they call a "feature" ala MS-Speak. Hmm... I'll have to start investigating this. I just assumed they were case-sensitive... :(

  • Comment on (Ovid) Re: DBI not letting bind varibles in if you use a varible for the statement.

Replies are listed 'Best First'.
RE: (Ovid) Re: DBI not letting bind varibles in if you use a varible for the statement.
by jptxs (Curate) on Sep 06, 2000 at 20:37 UTC
    that is the code, except for the exceedingly long SQL statement - which was built for me by a tool and works fine. The suggestion about using single quotes actually did fix the issue - was that just a side effect?

    Also, I don't know about other DBs, but Oracle's column names are not case-sensative. The all caps thing is how I learned SQL from the get-go (been writing SQL long before Perl :)

      That is the code, except for the exceedingly long SQL statement - which was built for me by a tool and works fine. The suggestion about using single quotes actually did fix the issue - was that just a side effect?
      The "exceedingly long SQL statement" was the problem, if changing from double quotes to single quotes fixed it. You must have some @, $, or \ somewhere in that string.

      When people post "this breaks" but don't post the code that actually breaks, all we can do is guess. On Usenet, it's a common practice to simply make up a nonsense answer like "the problem is on line 48, or near there". {grin}

      But yes, changing the stuff you posted from double to single quote wouldn't have changed a thing, so whatever your secret SQL is, that's where the problem was. Please keep that in mind next time. Most of the people answering questions here are not asking for things idly. {grin}

      -- Randal L. Schwartz, Perl hacker

        here's the SQL, by popular demand:
        SELECT SC_BASE_APPT.CALL_ID, SC_BASE_APPT.STATUS FROM SC_BASE_APPT , SC_BASE_INFO WHERE ( (SC_BASE_INFO.TRANS_ID = SC_BASE_APPT.TRANS_ID) ) AND SC_BASE_APPT.SC_ID = ? AND ((to_number(SC_BASE_INFO.AP_START) <= ? AND to_number(SC_BASE_INFO.AP_ +END) >= ?) OR (to_number(SC_BASE_INFO.AP_START) <= ? AND to_number(SC_BASE_INFO.AP_E +ND) >= ?))