Viewing 15 posts - 54,691 through 54,705 (of 59,089 total)
A big key here is that David DIDN'T even use a function (although you could if it's for RBAR GUI code)... it splits a whole table's worth of information in...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 7:16 am
Heh... I cheat like hell... load up one staging table with everything... delete the dupes with the "earliest" information... flip the pass-through-view to look at the new table... drink beer...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 8:56 pm
Ramesh Lende (10/8/2007)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 8:47 pm
Backups... if for nothing else, to clear log files that are getting big and growing.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 8:44 pm
Most people recommend against it for many reasons... most of them are good, some are not... but you could put a view in the Master database and that would draw...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 8:34 pm
nba (10/4/2007)
The problem now is not the trigger but why it was there and not documented.
Simple... database is not correctly locked down for changes. No one but DBA's should...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 8:21 pm
Works fine for what you have... no primary key.
To help, I need to know what you expect the output of your first post to be...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 7:58 pm
You'd need to split out the images into separate files...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 5:25 pm
We handle some pretty heavy loads, as well, but on the SQL Server side... that is, when folks stop trying to write Oracle code for SQL Server ๐
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 5:21 pm
Even better!
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 5:18 pm
David (10/6/2007)
Thanks Jeff! I was hoping you would respond. You always have such brilliant responses!!Many thanks!!
Heh... thanks David :blush:
But, Serqiy's observations are spot on and I was actually...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 5:01 pm
Jack Corbett (10/8/2007)
I had a solution I was going to post but Jeff's was faster by magnitudes. I'd go with his solution.
Heh... :blush: Thanks for the Kudo, Jack......
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 4:51 pm
Sergiy (10/8/2007)
I believe this topic is a perfect illustration for the article "Why programmers cannot program?".They take care about everything - formatting, performance, style, but ignore building correct algorithm absolutely.
Absolutely...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 4:45 pm
Sergiy (10/6/2007)
What if nobody made any order on Tuesday?
Jeff, don't you think the Thursday calculation should include zero orders for Tuesday, not whatever number...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 4:41 pm
Guess my other question would be... why do you even need this type of info in a fact table or dimension? This should be simple lookup data.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2007 at 4:27 pm
Viewing 15 posts - 54,691 through 54,705 (of 59,089 total)