Viewing 15 posts - 52,621 through 52,635 (of 59,091 total)
That's normally the way I do it, too.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:29 pm
Absolutely perfect, Chris... I've always wondered why people try to do it the hard way.
Another way to do this is to simply have 2 tables and a view. While...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:20 pm
Craig,
This would be a lot easier to test code for if you provided some data and table schema info. See the following for how to do that effectively...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:11 pm
First, since you don't have HU_ID in any part of your query, you need to tell us which table it's in.
Second, I think you also have dupes in the bcustomer_notification_call_list...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:05 pm
When you created the new xp's, did you make sure that you created them in the Master database?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 5:53 pm
Same subject... slightly different slant...
I, for one, would like to congratulate this fine community of professionals such as those witnessed in this thread. The subjects of auto-incrementing columns and...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 5:09 pm
Heh... I love instant confirmation! Thanks, Chris!
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 4:28 pm
antonio.collins (2/11/2008)
i'm confused. assuming there's some column that can order the payments sequentially/chronologically, can't this be solved with a simple self join?
Yep... and that "simple self join" is classified...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 4:22 pm
Don Bernstein (2/11/2008)
unless you think that SqlServer may some day refuse to convert the Datediff result to a datetime field
That's kind of what I'm thinking... doesn't take much extra time...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 4:14 pm
Could it be that simple? Your original post said you added an extended sp called "xp_add" yet in your latest post you say you are using "xp_add1". Do...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 4:08 pm
John Beggs (2/11/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 4:01 pm
Print commands, like rowcounts, can sometimes be made to bubble up through the app.
However, I agree... I prefer to use Raiserror properly rather than the likes of PRINT......
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 3:54 pm
ALZDBA (2/11/2008)
Don't exceed thier level, but hand over the needed hints, so they can figure out for themselves your guidance makes sence !...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 7:10 am
Ok... what would you do to return more information from each row using that method?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:50 am
Heh... I guess I get carried away a bit on the "little" stuff, Johan. 😉 But, you're correct... it's a crucial error that both Newbies and those that write...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:42 am
Viewing 15 posts - 52,621 through 52,635 (of 59,091 total)