Re: Conditionally Adding SQL

1) Long parameter lists are easy to maintain because we have text
editors (Hell! ever use the C increment macro stuff?) that take
regular expression, numeric sequencing. etc.

Just because you can automate some of the tedious parts does not make it a
better solution. I *could* build a lot of silly things through code that I
would never do by hand, but will only do so if they're useful. In this
case, I think it is silly. If you build the procedure to accept 100
parameters and then later decide to support 200 or 500, you have to go
modify the code.

2) SQL injection is a major threat in the real world when you allow
interpreted strings -- read the trade press (TJ Max, et al)

If you are not blindly EXECing the strings that are passed in, I'm not sure
where the threat is. Let's say you are splitting strings, what makes
passing a string into a VARCHAR parameter any safer than passing that same
string into a VARCHAR parameter as part of a list? You're still doing the
same thing with the individual string values eventually. If you use a safe
method to split the elements in the list then this becomes moot. Can you
provide some useful, non-Chicken Little advice, and demonstrate how to SQL
inject the code I presented here: http://tr.im/v4ew

3) If you write your own parser. then you are REQUIRED to return
EXACTLY the same error codes as a parameter. Think about it!! The
procedure for "<verb>_foobar()" ought to return the same errors as
"<verb>_<many foobars> ()"
Want to try to guess the future ?

I don't think splitting up a comma-separated list really qualifies as
"writing your own parser." But there is still no reason why you can't have
full validation of individual values in the list; several of us have
demonstrated it in the past and it is not that difficult. Your choice to
not read and become familiar with approaches that don't require 1000
parameters should not be paid for by everyone you give advice to.

4) Whatever local date format is, adjust your UDF parser on the fly!
OOPS! this configuration and context management.

Who is passing in local date formats? When did we start talking about
dates? Just because you don't understand that SAFE date formats in SQL
Server are YYYYMMDD (not YYYY-MM-DD or crap like m/d/y or d/m/y), does not
mean the rest of us are ignorant about it.

.

Relevant Pages

  • Re: Form variable in query
    ... Access expects literal date strings to be in one of two formats. ... Dim var1 As Date ... The following SQL returns 26 records ...
    (microsoft.public.access.queries)
  • Re: SQL Injection with JDBC
    ... fixed SQL instead of building the SQL dynamicly. ... At most, they may have included clauses dynamically, but in my own experience that type of code is very messy to maintain, and one winds up selecting entire query strings based on user input, not building the strings up piecemeal. ... The thing that Arne say "should not be used in real-world projects" is non-parametrized, non-prepared statements where the SQL string is built up entirely in text then executed as such. ... The thing that we recommend is the use of PreparedStatement to embed type-safe parameters into SQL statements that are not subject to such flaws. ...
    (comp.lang.java.programmer)
  • Re: 3vl 2vl and NULL
    ... "strings" specifically are so interesting to you. ... input that can be cast to a numeric type, ... but it is not expected that the DBMS is forcing you to do so. ... It seems you can't accommodate the SQL outcomes because it doesn't have a "shape" that you are comfortable with. ...
    (comp.databases.theory)
  • Re: Performance Problem with Stored Procedure calls to Sql Server
    ... Look at this in SQL profiler. ... The strings contain XML. ... > Dim oRs As ADODB.Recordset ...
    (microsoft.public.data.oledb)
  • Re: Linq; expression parser?
    ... object based query at runtime and had to revert to stored strings. ... but if I had the need to write dynamic SQL inside the ...
    (microsoft.public.dotnet.languages.csharp)
Loading