Re: (Fwd) DBI Dilemma

Thank you Blake,

So it turns out that a lot of other responders on dbi-users had falsely assumed 
you were using a standard SQL-native DBMS and so a lot of details about eg 
quoting with double-quotes or backticks etc are not necessarily applicable to you.

What actually matters is that your problem is internal to a Perl module itself, 
eg DBD::CSV or a related dependency included with itself or with DBI that 
DBD::CSV uses to parse whatever SQL you're writing.

You need to look at the documentation for what SQL DBD::CSV can handle, or maybe 
it has a bug and you've exposed it, eg that quoting DESC is supposed to work.

One thing I recommend is look for case-sensitivity issues.  In standard SQL, 
quoting an identifier makes it case-sensitive while unquoted is not, so you may 
have to check what case is being compared with.  You may have also found a bug.

If for some reason this problem becomes intractable (it shouldn't be), if you 
can at least read in each CSV file to a Perl array of Perl hashrefs, a typical 
DBI select-all convention, you could try using my Set::Relation::V2 module to do 
SQL-esque munging/queries of those.

-- Darren Duncan

On 2015-08-18 7:21 AM, Adkins, Blake wrote:
> Let me do a better job of explaining the situation. We use GE's Cimplicity to monitor and control a SCADA system. GE provides an interface to the database but it's very limited. The easiest way is to export to a .csv file and operate on that and then import changes. My script works on the .csv file using dbi:CSV:f_dir and pointing to different files for different projects. The problem comes when I try to include DESC in SELECT or WHERE. I have tried 'DESC', "DESC" and `DESC`. The last two fail at run-time. The first one doesn't fail but it returns something like
> 	PT_ID,DESC
> 	PT_1,DESC
> 	PT_2,DESC
> 	...
> 	PT_N,DESC.
> I'm using the DBI module in Perl, would this be better with the other modules mentioned?
>
> Blake
>
> -----Original Message-----
> From: Darren Duncan [mailto:[email protected]]
> Sent: Tuesday, August 18, 2015 12:19 AM
> To: Adkins, Blake; [email protected]
> Subject: Re: (Fwd) DBI Dilemma
>
> Blake, something you need to clarify is what you are querying against, is it the SQL database or the .csv file?  Either the .csv thing is a red herring or it sounds like you're using DBD::CSV, so which is it?  The solution depends on this. -- Darren Duncan
>
> On 2015-08-17 2:42 PM, [email protected] wrote:
>> ----- Forwarded message from "Adkins, Blake" <[email protected]>
>> -----
>>
>> Date: Mon, 17 Aug 2015 17:51:41 +0000
>> From: "Adkins, Blake" <[email protected]>
>> To: "[email protected]" <[email protected]>
>> Subject: DBI Dilemma
>>
>>      Tim,
>>
>>      I've been using your module to enable people in my group to do searches on a database that is regularly
>>      backed up as a .csv file. The problem here is with a particular column name. Of the 140 columns in the
>>      database, one is named DESC, short for description. This was established well before my time at the
>>      company and I believe the name comes from GE who makes the Cimplicity product. If I try to do a SELECT
>>      using that column, the script dies, or quietly passes DESC in the column header and all the rows. I've
>>      tried to figure out how to get around it without success. Do you have any suggestions aside from
>>      renaming the column? (I was thinking along  the lines of escaping
>> the name)
>>
>>      Thanks,
>>
>>      Blake Adkins
>>
>> ----- End forwarded message -----
>>
>