Viewing 15 posts - 7,396 through 7,410 (of 7,608 total)
My best (educated) guess based on what you've posted so far is:
A filtered index on ISAPPLIEDFORSPECIFICDAYS = 1, including the daily columns.
That index may or may not help -- you'd...
June 4, 2012 at 1:49 pm
CREATE NONCLUSTERED INDEX [IDX_ApplAcctNo] ON [dbo].[tableB]
(
[applAcctNo] ASC
)
Since tableB already has that index, I suggest changing its definition to also contain the acct_nbr and the bit flag. Then...
June 4, 2012 at 11:46 am
So much for a UNIQUE Clustered Index and the performance that will offer.
The way around this problem is to determine what makes each row UNIQUE in your table while considering...
June 4, 2012 at 9:06 am
The DBCC SHRINKDATABASE() will shrink the log file also, so you don't need to do it separately; thus, you can just comment out the "DBCC SHRINKFILE".
June 1, 2012 at 5:12 pm
You can specify a batchsize for a bulk load, and SQL then commits every time after that many rows are loaded (obviously you definitely want to specify a batchsize for...
June 1, 2012 at 4:59 pm
As for the restore, it's very easy to create a script to have SQL restore the last backup of a db.
June 1, 2012 at 4:48 pm
Maybe, then you could also do this:
select
a.* -- to save time, should define all columns you want to return
from
dbo.Appointments a
...
June 1, 2012 at 1:04 pm
I think this will do it:
WHERE
DIAG1 NOT LIKE 'C[0-8][0-9]%' AND
DIAG1 NOT LIKE 'C9[0-7]%' AND
DIAG1 NOT LIKE 'D3[7-9]%'...
June 1, 2012 at 12:41 pm
I strongly suspect you will want to see more details on the last appointment than just the date:
SELECT
CustomerId, AppointmentDate, ...
FROM (
SELECT *,...
June 1, 2012 at 12:35 pm
but that does not mean that someone else didn't change something
As Lynn has stated, that can happen even without any change being made to anything.
SQL only provides ORDERing if you...
May 31, 2012 at 4:08 pm
Yes, your queries will be vastly faster if you cluster on add datetime rather than identity. Hopefully your queries are then typically like this:
SELECT
SUM(...) AS...
May 31, 2012 at 3:53 pm
An occassional highly unusual exception doesn't validate the horrible idea in general of identity as the default for a clus key.
May 31, 2012 at 2:30 pm
True, there could be special situations.
you could potentially have a very large and active table that is in a database mirrored over a slow wan connection.
If you're trying to mirror...
May 31, 2012 at 2:14 pm
Other than logging-type tables, where the clus key value is essentially irrelevant, I can't imagine any case where identity would be the proper clus key on business data.
Sure, for some...
May 31, 2012 at 2:05 pm
There are vastly better ways to stress that in general a table needs a clustered key than to have the damaging and false notion that it should be an identity...
May 31, 2012 at 1:57 pm
Viewing 15 posts - 7,396 through 7,410 (of 7,608 total)