Viewing 15 posts - 39,886 through 39,900 (of 59,072 total)
vyas (2/5/2010)
Use union
Please show us how. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 9:03 pm
If you use WITH(TABLOCKX), no one but you will get in once everyone else gets out. The "X" stands for "exclusive".
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 9:02 pm
Cool. Thanks for the info.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 9:00 pm
Jim,
There are a lot of things that can affect performance. As a result, we need more information. Take a look at the article in the 2nd link in...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 8:52 pm
Make a swag... count the number of rows per month and then extrapolate against the total number of bytes the table and its indexes hold. For example... if a...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 8:46 pm
sgambale (2/4/2010)
(EventTime datetime)
insert into sg values('02/01/10 07:17:00')
insert into sg values('02/01/10 07:33:00')
insert into sg values('02/01/10 07:46:00')
insert into sg values('02/01/10 08:10:00')
insert into sg values('02/01/10 08:37:00')
insert into sg values('02/02/10 07:57:00')
insert into...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 8:37 pm
Actually, if you can restore the next hour's worth of backups now, you can get away with as few as 42 of the parameters.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 8:15 pm
If you passed the information to a stored procedure instead of using embedded SQL, this problem and some of the security problems that Luke mentioned would simply disappear.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 8:02 pm
The SQL Server service must be logged in as a Domain account that can see the path that you're using xp_CmdShell to point to.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 7:55 pm
If, as you say, the historical doesn't change, then just pre-aggregate it and store it in a reporting table. If you're careful about how it's done, then there's no...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 7:54 pm
amoericke (2/5/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 7:50 pm
Oddly enough, one of my toasters also begins with a "T"... T-SQL. My other toaster is my trusty pork chop launcher... heh... I've only had to change the bands...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 7:44 pm
I'm pretty much good with the above mostly for readability and because SQL was originally designed to be "English like" which doesn't have commas at the beginning.
People who put commas...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 7:38 pm
Absolutely no problem... Just wanted to make sure everything was ok with you. Thank you for the come back.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 7:05 pm
paul.knibbs (1/20/2010)
Jeff Moden (1/16/2010)
If you're using certain other methods to do the hashing (I forget what they're called... MD5???), then the additional checking will not be necessary.
Even with MD5 or...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 6:39 pm
Viewing 15 posts - 39,886 through 39,900 (of 59,072 total)