Viewing 15 posts - 58,996 through 59,010 (of 59,063 total)
Heber!
I've been looking for a really simple way to "add a running number" to a SELECT for a long time! Thank YOU! That IS a really neat trick!
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2004 at 9:20 pm
David,
Thank you for your kindness...
I've sent the code samples to 4 different people and have run it on the server at work. In every case, your code with the <>...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2004 at 7:17 am
David,
I'd say that I owe you an apology!
Your code does, in fact, return all of the rows expected! I don't know what I...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2004 at 6:16 am
Ugh...
No cursors...
although it can certainly be done with one
...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 6, 2004 at 6:10 am
BJure,
When you say you tested "IT" and NOT EXISTS was faster, what is "IT"? In other words, what was "NOT EXISTS" faster than? Thanks.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 6, 2004 at 6:05 am
Hey Matt,
I get it... when sorted in the order of the first column, you want to show only those rows whose value in the third column has changed from the...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 5, 2004 at 10:03 pm
All of the methods about system tables and procedures that begin with "sp_" are great... but if all you want to do is get all the columnar info to show...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 5, 2004 at 9:53 pm
Cmore,
Here's one more little "secret" of mine
... I never use BCP to import to a "live" table ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2004 at 7:21 pm
It, of course, depends on the SELECT statement in the NOT EXISTS but, I'd have to say "Yes", in most cases (was going to say ALWAYS but, sure-as-shootin', somebody would...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2004 at 7:08 pm
Just a note... The IDENTITY function can only be used when the INTO clause (as Figaro did) is also present or you will get the following error...
Server: Msg...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2004 at 5:44 am
Haven't tested this but should work just fine. Notice how DATEADD was used to subtract 4 months from the current date... not a job for DATEDIFF as many would think...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2004 at 5:24 am
It won't actually report what constraint was violated but it will reject any record to the "error log" that either violates a constraint, key, foreign key, data-type, or column width. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2004 at 7:41 pm
Thought I'd clarify my statement about using an Outer Join as a replacement for a "Where Not In"...
About outer joins... I'm sure you've heard all sorts of horror...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2004 at 6:53 am
If you are using an outer join as a replacement for a "WHERE NOT IN", then the filter must be in the WHERE clause as in Gary's second example above.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2004 at 6:20 am
Use CASE as a substitute for DECODE. Of course, "equivalent keywords" usually are not "equivalent" and will require a bit of rework.
Don't know what DISTINCTROW is... and don't want to...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2004 at 6:15 am
Viewing 15 posts - 58,996 through 59,010 (of 59,063 total)