Viewing 15 posts - 406 through 420 (of 1,065 total)
Setting the recovery model to SIMPLE isn't going to help here. Regardless of the recovery model, a single statement has to be atomic (it works completely or not at all),...
September 25, 2009 at 1:45 am
If that single job backs up everything you need, and the databases haven't grown significantly since the last backup, then, yes, the Run Duration from the job history should be...
September 25, 2009 at 1:27 am
This is what your index will actually look like
1$adams
2Ajack
3*anna
4&smith
5bamy
6!sue
7@rose
1. select na from t where ch = '!'
Result :index scan
id is the first column of your index, not ch, so...
September 24, 2009 at 6:15 am
No you can't replicate these.
The databases involved in transactional replication don't have to have exactly the same schema, so an index on the publisher may not exist on the...
September 24, 2009 at 2:08 am
niall.baird (9/23/2009)
September 24, 2009 at 1:55 am
Leaving aside any arguments/discussions about having/not having a primary key on every table...
No, you don't need to have a primary key to use a trigger.
What you do need, is...
September 24, 2009 at 1:45 am
If it is the OR that is causing the scan, you may get a better plan by using a UNION to get rows from either side of the OR. Make...
September 23, 2009 at 2:52 am
We have one prod server and are planning setup high avialabily.
If you only have one physical server, then you can rule out high availability.
For any form of high availability, you...
September 22, 2009 at 2:58 am
so I'll end up with 6-7 Status tables - haven't seen that before
That's not uncommon. The rules of data modelling say "One table, One purpose", so to use one...
September 21, 2009 at 10:31 am
Active might mean different things for Products or Customers, but the status is the same and I don't think you gain anything by putting it in a separate description table.
I...
September 21, 2009 at 8:49 am
I'm not going to come down on one side or the other on the PRIMARY KEY debate... as far as I can see, it's a question of semantics... the purpose...
September 19, 2009 at 2:56 pm
crainlee2 (9/19/2009)
Wouldn't the Optimizer scan the index instead of scanning the data records? If so, I would think that would offer some efficiency.
You are absolutely right Lee. It would scan...
September 19, 2009 at 2:32 pm
--SELECT * FROM #TestTable WHERE UniqueVarChar = 'FC6AC668-45E2-473A-9CBD-2A9126CE536E'
--SELECT * FROM #TestTable WHERE UniqueVarChar LIKE '%BD-2A9126CE53%'
--SELECT * FROM #TestTable WHERE UniqueVarChar LIKE '%FC6AC668-45E2-473A-9CBD-2A9126CE536E%'
Lee
Thanks for posting your results.
As Grant said, sometimes indexes...
September 19, 2009 at 3:02 am
There's a good chance that this
(empcode between '99201' and '99205' or empcode between '99211' and '99215' or
empcode between '99241' and '99245' or empcode between '99354' and '99355' or
empcode...
September 18, 2009 at 12:03 pm
Please post the stored procedure code.
Without that, any suggestions will have to be based on pure guesswork.
September 18, 2009 at 10:14 am
Viewing 15 posts - 406 through 420 (of 1,065 total)