February 2, 2015 at 9:06 am
ok this is something of a best practice of mine in my queries
I always do
WHERE 1 = 1
I can't remember where I picked this habit up and I'm one of the few in my current workplace who use this,so I've been wondering anyone else besides me who does this.
February 2, 2015 at 9:49 am
Resender (2/2/2015)
ok this is something of a best practice of mine in my queriesI always do
WHERE 1 = 1
I can't remember where I picked this habit up and I'm one of the few in my current workplace who use this,so I've been wondering anyone else besides me who does this.
All the time during development. It depends whether you put commas before or after your output columns.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
February 2, 2015 at 9:55 am
Resender (2/2/2015)
ok this is something of a best practice of mine in my queriesI always do
WHERE 1 = 1
I can't remember where I picked this habit up and I'm one of the few in my current workplace who use this,so I've been wondering anyone else besides me who does this.
I have done this when programmatically building dynamic SQL to make adding ANDs or ORs easier, but that's about it.
February 16, 2015 at 4:00 am
I used this when creating dynamic sql query as default search condition
February 16, 2015 at 4:12 am
I hate seeing that in queries.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 16, 2015 at 7:08 am
February 16, 2015 at 7:16 am
I do when I'm troubleshooting queries, it saves constantly having to delete and re-enter AND's if I'm trying to establish what's causing a report to return unexpected data.
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
February 16, 2015 at 8:55 am
GilaMonster (2/16/2015)
I hate seeing that in queries.
Ditto that.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 17, 2015 at 10:43 am
I use it regularly, but only when I'm developing queries or in ad-hoc queries.
Interesting that I saw this post just now. I just finished removing one of these from a production stored procedure.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
February 17, 2015 at 11:18 am
The only purpose I know of for it is the one Lynn stated. In production code, concatenating strings into SQL statements tends to be bit on the dangerous side, so don't do it.
February 17, 2015 at 5:44 pm
Jeff Moden (2/16/2015)
GilaMonster (2/16/2015)
I hate seeing that in queries.Ditto that.
Agree.
The ancient "WHILE 1=1" had an excuse because the procedural languages never had any decent multi-exit loop control flow concepts (even T-SQL with CONTINUE and BREAK still needs that), but surely we don't want anything like "WHERE 1=1" in any SQL dialect's DML.
Tom
February 18, 2015 at 6:39 am
CELKO (2/17/2015)
Ditto that.
Agree.
Department of Redundancy Department 🙂
🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
February 18, 2015 at 7:12 am
Jeff Moden (2/16/2015)
GilaMonster (2/16/2015)
I hate seeing that in queries.Ditto that.
+1 to all of the above.
#1 Reason my production SQL does not work as expected.
It is a code structure older than SQL and is not a best practice in any language.
It is like saying While Constant = the same Constant do something.
EDIT: I see I am not the only one that remembers how horrible this is in any language.
February 18, 2015 at 9:39 am
CELKO (2/18/2015)
I see I am not the only one that remembers how horrible this is in any language.
Remember it from Assembly languages? If you dropped it, the line count would change and would mess up hardwired jumps. :crazy:
Wasn't the syntax different for the 1=1 we are talking about? like C1 = 1
In assembly every check is for bit value at some register or Port, so there are to many things you could be remembering.
I do remember in Assembly for 80386 and later FPUs that you checked C1 (bit 9 or condition one) if bit 6 (stack fault) equaled one to see if it was stack underflow or overflow.
If these Condition checks got confused with constant checks in the executing code then it would miss the jump to peek at the correct port and would just keep trying cause constant 1=1 but the next register was not there because condition 1 = 1 fault had occurred so constant 1 still equal 1.
February 18, 2015 at 11:24 am
CELKO (2/18/2015)
Oh Ghod! We are old! :crying:And we had some weird undocumented instructions. The BLISS language out of Carnegie-Mellon had a final pass in their compiler to look for these things. I favorite was a single VAX instruction that compared x++ to x++ and if it was TRUE (always) then increment the results. How to add 3 in one command! :sick:
I vaguely recall some runaway process on ENIAC (the VAX that was in play when I went to college, not the original "vaccuum tube" iteration) that sounded a lot like that type of incrementer. It skipped right past the stop criterion (x==5) and kept on looping happily thereafter.
God those were the good days :w00t:
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Viewing 15 posts - 1 through 15 (of 52 total)
You must be logged in to reply to this topic. Login to reply