Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

avik (3911)

avik
  (email not shown publicly)
Yahoo! ID: topchyan (Add User, Send Message)

Journal of avik (3911)

Friday January 28, 2005
09:49 AM

Cold ConFusion and SQL Butcher

[ #22926 ]

My company uses only ColdFusion and SQL Server, so I'm learning new things, for example:

  • In Access I used to write IIf(if_condition,true_result,false_result), but now in SQL Server I have to write CASE source_value WHEN target_value THEN true_result ELSE false_result END
  • Never thought that select str(3.1415927) as foo would return 3
  • How awful that Format(Now(),'yyyy-mm-dd') must now be written as left(convert(varchar(12),getdate(),120),10) to get me the same output.
  • String & ' ' & Number & ' ' & String works fine in Access, but in SQL Server it must be written as string + ' ' + Cast(number as varchar) + ' ' + string but why the pluses if we don't even add anything, we're concatenating, right?
  • Cold Fusion's cfquery causes all single quoted characters to be auto-escaped, by doubling them. Good in 90% of cases, but what if you are doing dynamic SQL think with interpolation of single-quoted values? Then that becomes a mess. You must now use tag in order to to be used in PreserveSingleQuotes(sql) manner. This is not intuitive. I spent about an hour to find an answer.
  • Documentation sucks big time for SQL server. Documentation is little better for ColdFusion, but not clear enough in many cases.
  • I deeply miss relative simplicity and friendly uglinness of Perl + DBI + DBD::ODBC + CGI.pm
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I find most of what I need in the 'Help' for the MS Query Analyzer. I can't stand all the proprietary built-in functions of different databases though. If I had a choice, I'd use only generic (as generic as possible) SQL, and munge the results later in the code. But that isn't always possible, and some languages don't make it as easy to munge as perl does, so in our (non-perl) code we have a home-grown 'sql_parse()' function which tries to convert these things and handles most of it, but there's still alot