Viewing 15 posts - 49,081 through 49,095 (of 59,099 total)
Cool... thanks for the feedback, Lynn. And, glad it all work.
Michael, nice job if you don't mind me saying so. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 5:15 pm
ALIF (7/24/2008)
either use this thingsshrink tempdb,
or
detach the file and attach with a new one with 0 bytes
or still you cant do
just restart the sql services, everything will be refreshed.
Shrinking...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 5:13 pm
GilaMonster (7/24/2008)
angie stein (7/24/2008)
Brandie Tarvin (7/24/2008)
Does this technobabble make sense?
Ok, so it sounds like you should usually restrict the growth (esp. in prod), unless there's a good reason to do...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 5:04 pm
nisan.al (7/24/2008)
But by the way, tempdb doesn't have to be in the same drive as the operation system you can change...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 6:08 am
Thanks for taking the time for that feedback, Hugo. I appreciate it.
Running totals are no excuse for using cursors... not even for display.
http://www.sqlservercentral.com/articles/Advanced+Querying/61716/
So far as the "bin packing" thing...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 6:05 am
or because you run into one of the very rare problems where a cursor actually runs faster than a set-based solution
Hi Hugo,
Do you have an example of when that might...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 5:25 am
rames.net (7/21/2008)
How can we handle the situation if the tempdb space was full?reply with more than 2 diff answers?
Your turn, Pal... how about some feedback. We need at least 2...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 4:58 am
nisan.al (7/24/2008)
So there are two options:
1. some definition are wrong - check if tempdb deifintions are set to ...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 4:56 am
So, do you have a grip on generating the test data or do you still need a bit o' help on that?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 4:48 am
Thanks, Jonathan...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 4:40 am
pockeyfan (7/22/2008)
Sergiy (7/22/2008)
First, there is "error" message with
update t1as "t1" could not be found
Can you post the error message?
Here is the error message:
Number (208) Severity (16) State...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2008 at 12:04 am
rbarryyoung (7/23/2008)
hmmm (scratches head) I guess I missed that transactional replication was involved.:ermm:
Heh... I missed that data marts were involved. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2008 at 11:39 pm
If you want the object ID from the name, why not just use...
SELECT OBJECT_ID('objectnamehere')
There are several system functions that will help keep you from redeveloping the wheel... just look them...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2008 at 11:36 pm
Ummm... let's do a small test on the "bad" machine... if you open a "Command Prompt" window, type DIR and press {Enter}, does it return anything? And, no, not...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2008 at 8:47 pm
If transactional replication does not replicate truncations, then there is no need to audit inserts to rebuild a truncated table because you can always get it back from the replicated...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2008 at 8:36 pm
Viewing 15 posts - 49,081 through 49,095 (of 59,099 total)