my $sql = "DECLARE \@log varchar(5) SET \@log=$tim Update dbo.tltime s
+et logtime = \@log";
Notice that the "@" signs need to be escaped - because "@log" is intended for the SQL server, not perl. perl needs to be told to ignore the @, which you do by expressing it as "\@".
On the other hand, you wan to tell SQL the value contained in the perl "$tim" variable, so you require perl's interpolation for THAT variable, so , use double-quotes.
Syntactic sugar causes cancer of the semicolon. --Alan Perlis
| [reply]
[d/l] |
you wan to tell SQL the value contained in the perl "$tim" variable, so you require perl's interpolation for THAT variable, so , use double-quotes.
Wrong. Most SQL engines require single quotes for values, and double quotes for otherwise illegal identifiers.
But don't use single-quotes, either. Use placeholders and only placeholders for any value passed to the database. Forget that quote exists at all. That method should be restricted to DBDs.
Use quote_identifier when you need to pass variable identifiers (most times, names of database objects like tables, views, columns, triggers, sequences, procedures) to the database.
Update: Sorry, I wrote nonsense.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
Wrong. Most SQL engines require single quotes for values, and double quotes for otherwise illegal identifiers.
The "Wrong" bit is debatable Alexander as I believe the node you replied to was attempting to comment on the inclusion of @something in the same SQL which included $tim. I read the node as you could use single quotes around the SQL string to avoid @something being interpreted by Perl as an array but since you also include $tim you need to use double-quotes (around the SQL) and escape the @something.
However, other than that I agree with most of your points and advice except to point out a slight snag with the quote_identifier. Most databases have some rather nasty rules about quoted and unquoted identifiers like some uppercase unquoted identifiers, some lowercase them and some keep the case. Once you use quoted_identifier in many databases you have to get the case exactly right. Some also require table/column names the same as reserved words to be quoted. All I'm really saying is it is not clear cut whether to use quote_identifier always.
| [reply] |
While I disagree with your evaluation of the information as "wrong", I accept the point that SQL usually requires single-quoted literals, and placeholders are good.
Until O.P has comments otherwise, I presume the issue is resolved, and we can avoid unnecessary debate and contention. I understand what you meant, and agree with your recommendation. My disagreement with your evaluation is irrelevant and non-productive, but it is there for the record. "Wrong" unfortunately has an accusatory quality, and invokes an emotional response. May I gently suggest that when you express disagreement, to please consider using something less potentially inflammatory , unless , of course, the issue is blatant or egregiously misrepresented.
Syntactic sugar causes cancer of the semicolon. --Alan Perlis
| [reply] |