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

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.

The "Wrong" bit is debatable

No, it's just wrong, regarding the quotes. I totally lost the thread context when replying to Re^3: SQL Query error while executing in perl. Is it possible to execute these Scripts??. All that I wanted to comment was the possible SQL injection ...

my $sql = "DECLARE \@log varchar(5) SET \@log=$tim Update dbo.tltime s
+et logtime = \@log";
#                                   ... here --^
[download]

... combined with the words "so , use double-quotes", this lead to ...

my $sql = "DECLARE \@log varchar(5) SET \@log=\"$tim\" Update dbo.tlti
+me set logtime = \@log";
#                                             ^^    ^^
[download]

... in my mind. Which is even worse than what was posted. This lead to my "Wrong." posting. Still, at least MySQL allows values in double quotes, unless ANSI QUOTES are enabled.

Regarding problems with quoted identifiers, you are right. Quoting identifiers can cause more problems than it is worth.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

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

Sorry, I lost the thread context and wrote nonsense.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)