Viewing 15 posts - 50,356 through 50,370 (of 59,091 total)
Wayne,
Take a look at the following URL and warp the technology to do exactly what you need...
http://www.sqlservercentral.com/articles/Advanced+Querying/61716/
It will be nasty fast... methods used will take care of a million rows...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 10:59 pm
Not good... you can get dupes that way because of the relatively narrow INT range that CHECKSUM offers compared to the binary range of NEWID()... here's the proof of the...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 10:50 pm
No problem. Thank you for the feedback.
Generally speaking, folks like to see running balances on their monthly reports. Take a peek at the following article for a super...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 10:08 pm
wgarces,
See the following article... it covers this type of concatenation and a couple of related pitfalls to avoid...
http://www.sqlservercentral.com/articles/Test+Data/61572/
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 9:41 pm
I don't believe that works the way the OP posted... that will only give 1 employee name per company.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 9:40 pm
So... did it? 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 9:34 pm
Yep... move the process to a data base that uses the SIMPLE recovery mode. If you don't have one... make one... call it "ScratchPad" or "SandBox" or something like...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 9:32 pm
Why wouldn't the max ID for each BusKey contain the latest data? :hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 9:11 pm
Change the double quotes to single quotes...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:34 pm
First, the CONVERT on the datetime column will kill any chance of using an Index SEEK if the column is indexed. Second, you just need to add a simple...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:30 pm
Way too generic a question... but here's some generic answers...
You need to make sure the correct indexes are in place and that the queries can actually use them effectively. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:24 pm
What did you end up doing?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:19 pm
Let us know how it turns out, fosco...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:17 pm
Heh... I started reading this post and then saw your first reply... I knew you'd use the running balance trick... it just makes sense, here. Nicely done!
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:13 pm
I do have to ask the stupid question... you are running the code from the database that has the WRT_% tables in it, aren't you?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:00 pm
Viewing 15 posts - 50,356 through 50,370 (of 59,091 total)