Viewing 15 posts - 39,916 through 39,930 (of 59,098 total)
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
UT,
It's been a couple of days... how'd all that work out for you?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 6:05 pm
True enough. You should also mention that most UDFs aren't necessary either. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 6:03 pm
Brian.Dunat (1/23/2010)
This is the proper clustered index and it makes up the primary key on the table. This is a wealth management database, so the data that will be inserted...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 5:52 pm
dan.hare (7/30/2009)
Of course you can choose to report a date/time to whatever level of granularity you want.
Dead easy.
My point was that if you choose...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2010 at 5:40 pm
Viewing 15 posts - 39,916 through 39,930 (of 59,098 total)