Viewing 15 posts - 58,246 through 58,260 (of 59,067 total)
Interesting...
I may have a method that might even beat ASP.Net for performance but I need to know, does your table have an auto-numbering IDENTITY column? And, it doesn't matter if...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2006 at 9:28 pm
Too bad... I think this was homework and didn't see where Paul tried...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2006 at 4:46 pm
I don't believe it's returning the the latest identity value unless someone put a trigger on the table that does so. Check to see if there are any triggers on...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 5, 2006 at 9:40 pm
Sorry Kenneth... didn't exactly return the favor.
My Tally table is 9999 rows, single "n" column is INT with a Clustered PK.
The million row test table is made up of 6...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 5, 2006 at 7:19 am
Yep... I'd test it... "it depends" and the age old adage of "one measurement is worth a thousand speculations" still holds true. It's especially true in the world of multi-processors......
--Jeff Moden
Change is inevitable... Change for the better is not.
May 5, 2006 at 7:05 am
The following is wrong because it leaves out one entire second of the day...
BETWEEN '2006-05-01 00:00:00.000' AND '2006-05-01 23:59:59.000'
...depending on the source of the data, there could be thousands...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2006 at 10:12 pm
The reason I ask is because I DO have a Clustered Primary Key on the N column of my Tally table and here's the results I got from the 3...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2006 at 9:00 pm
Kenneth,
Does your Tally table have a Primary Key?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2006 at 8:09 pm
Jeff,
Great use of a Tally/Numbers table... is more than twice as fast as the WHILE LOOP method...
Shifting gears.... in your code, change this...
select @address = '1300 teseter 234'
...to this...
select @address...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2006 at 9:05 pm
Nope, no experience with GPS phone providers here, either. But what you have planned not only sounds very feasible, it sounds like a hell of a lot of fun, too! ...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2006 at 7:10 am
Here's the example xp_CmdShell code I will sometimes use... note that I always include the hardcoded DOS command DIR and I always include the path in double quotes to help...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2006 at 7:05 am
Not sure exactly how you would do it in DTS but I'm thinking that if you built some error logic around the fact that the files are empty and that...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2006 at 6:56 am
Another country hear from! Also, very neat, David. Interesting use of SIGN as a "lump detector".
Juliano... has one of these 3 solutions provided you with the answer you needed? They...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2006 at 6:50 am
... except to continue
Shows how much I use loops and I didn't read the code well enough.. Thanks for the clarification...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2006 at 6:38 am
VERY cool... I've seen a lot of hierarchical code in my time... this is great... First time I've seen anyone make good use of the CONTINUE statement without them getting...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2006 at 2:03 am
Viewing 15 posts - 58,246 through 58,260 (of 59,067 total)