Re: Conditionally Adding SQL

Tech-Archive recommends: Fix windows errors by optimizing your registry

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.

I am still waiting for you to post your full 250 parameter solution so we can all gauge the maintainability of that approach compared to passing the CSV string as a single parameter. Why will you not post your full solution?? What are you hiding - oh, the exact thing I'm talking about - not maintainable!

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

Very easily protected against using PATINDEX.

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 ?

Rubbish and to further that possible discussion - give an example of what you mean IN REAL WORLD code terms.

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

Rubbish - with dates AS YOU WELL KNOW you need to use YYYYMMDD in order to be consistent and not kill your patient (your words) because you anally followed some SQL date standard that HAS NOT BEEN IMPLEMENTED in SQL Server (there is no date suffix syntax).


Did you look at the code for "parm BETWEEN 5 AND 100" in a UDF
Parser? CAST() and loops

Rubbish - yet again, post a real world code sample so we can discuss.




"--CELKO--" <jcelko212@xxxxxxxxxxxxx> wrote in message news:f52ff421-c574-41e7-8024-8cd521e0fdfc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
You can easily write a more maintainable splitting mechanism that still guarantees data type, value validation, etc. <<

I wrote one of the first single statement blocks of "splitting
mechanism" code. I now HOW to do it; I earn most of my living fixing
mistakes in DDL/DML

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.
2) SQL injection is a major threat in the real world when you allow
interpreted strings -- read the trade press (TJ Max, et al)
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 ?
4) Whatever local date format is, adjust your UDF parser on the fly!
OOPS! this configuration and context management.

Did you look at the code for "parm BETWEEN 5 AND 100" in a UDF
Parser? CAST() and loops







.

Relevant Pages

  • Re: Writing parser right way in c#
    ... If you anticipate more patterns to be added after your parser is ... Best way is to define your tokens as regular expressions and use these ... a lexical analyzer, which converts the input stream ...
    (microsoft.public.dotnet.general)
  • Re: Regular Expression
    ... This isn't something that can be done in one regular expression, ... But none of these deals with nested patterns. ... you'll have to write a parser. ... rather has the nature of an Obfuscated Perl Contest entry, ...
    (comp.lang.perl.misc)
  • Re: Regular Expression
    ... This isn't something that can be done in one regular expression, ... But none of these deals with nested patterns. ... you'll have to write a parser. ... rather has the nature of an Obfuscated Perl Contest entry, ...
    (comp.lang.perl.misc)
  • Re: From a JavaCC code to Delphi? About grammars and that stuff that i dont know
    ... > a grammar. ... > through a regular expression. ... this mean i can find a similar RegEx for say, this query parser:)? ... So is best avoid doing this with RegEx? ...
    (borland.public.delphi.non-technical)