in reply to DBI binding field names as parameters

Well, as is you are selecting the (column) name. I suppose return of actual value of a parametric column name would depend on the capabilities of the database (& its driver) being used.

Else, you may need to evaluate the SQL much like one generates code (or a value) from a string in Perl via eval function.

Replies are listed 'Best First'.
Re^2: DBI binding field names as parameters
by sinterklaas (Initiate) on Jun 03, 2014 at 13:23 UTC
    Thanks for your quick response! Not sure if I fully understand what you mean with "you are selecting the (column)name." Good point about me forgetting to mention DB; I'm using MySQL (engine=MyISAM, not sure if that's relevant too?). I'll play around with  eval a bit then and see if I can get it to work. And if the answer simply is that my DB(&driver) does not support this, then I guess that's the answer to my question. At least I can get it to work, be it with a less efficient solution. Thanks again for your reply!
[reply]
[d/l]

      You are essentially doing ... 

      select 2

      [download]

      ... where you supply your own return value.

      If you are going to investigate "eval" like SQL function, just prepare the query in the loop & be done with it.

[reply]
[d/l]
        Ok. I do see the point about how this is supplying its own return value. But in other situations where I have used this, this same code has always interpreted my params instead of 'treating them literally' (not sure if this is the right way to put it). However, could very well be a characteristic of the DB/driver, in which case I'm not sure I'm too interested to really get to the bottom of it... :) Same with "eval"; as you say; I'll just go for the solution that works for me and worry about effiency again when it really becomes a bottle neck. Thanks (again :) for taking the time to respond!
[reply]

In Section Seekers of Perl Wisdom