Viewing 15 posts - 54,091 through 54,105 (of 59,098 total)
Thanks for the feedback, Elliot...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2007 at 6:01 pm
My Questions:
1. What are the best guidelines for managing these records AKA transactions
2. Should I create a summary table for monthly reports. I currently have a SQL Script that sums...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2007 at 5:56 pm
Thanks, Michael...
Say, when you get done with your adaptation, would you mind posting it? I'm not sure what all the to-do about the weekends part of your problem is...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2007 at 11:59 am
Heh... I wouldn't use a sequence in Oracle for this... wrong tool... doesn't buy you much. "RowNum Over Partition" might... gotta becareful how you do it so you don't...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2007 at 11:12 am
Ummmm... what makes you think blocking is so unhealthy? It's part of the normal process of INSERT, UPDATE, and DELETE... there will ALWAYS be some blocking particullary if you...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2007 at 10:23 am
You misspelled "Banana" as "Banan"
My recommendation would be to first make a lookup table that identifies which produce item is what. Then, try again...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2007 at 10:15 am
Ok, Nick... first, I gotta say that it's ok to post that much data, but if you're going to do that, the least you could do is make it easy...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2007 at 9:31 am
Looks good to me.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2007 at 7:55 am
Heh... thanks for the timing analysis, Michael. Guess I'm a purist, as well. Different kind, but a purist none the less.
In this case (except for the difference in...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2007 at 7:45 am
Alright, this looks simple when thought. It is like multiplication, and I could do it with "dreaded cartesian product" CROSS JOIN. This is crazy stuff. I am looking at tables...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2007 at 7:24 am
Ummm.... I'd check the intelligence factor... domething made the DB grow... what makes you think it won't happen again...
Shrinking DB's are one of the worst things you can do...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2007 at 11:06 pm
Generating and estimated execution plan is almost as good as running the code...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2007 at 11:05 pm
Simple math... divide by (1024*1024) (binary mb)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2007 at 11:02 pm
Brian is correct...
What I really want to know, is how that might have worked in 2k at all... would have given the same error with the code displayed by the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2007 at 11:00 pm
Ummm... you might want to be just a little careful with that code, Carl... actual execution plan show something worse than a cross-join at over 165 rows in one spot...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2007 at 10:53 pm
Viewing 15 posts - 54,091 through 54,105 (of 59,098 total)