Viewing 15 posts - 6,481 through 6,495 (of 6,568 total)
I think you can do that more easily, like so:
SELECT SUBSTRING(col1, (CHARINDEX('Website is', col1) + 11),
CHARINDEX(' because', col1, (CHARINDEX('Website is', col1) + 11)) -
December 6, 2010 at 3:47 pm
You're pulling data from the comma forward, so you need a leading comma as well as a trailing one.
December 6, 2010 at 3:33 pm
And Lynn's method declares the leap-year person to be 18 on the 28th.
Yes, but I think someone made that point that legally in some jurisdictions, a person with...
March 16, 2009 at 2:23 pm
It's not even guaranteed to be unique, which would be a bigger problem .
February 24, 2009 at 4:48 pm
Please tell me what is the most efficient way I can use to write the query?
Use EXIST with OR between to check the other tables; check the most likely table...
February 24, 2009 at 4:17 pm
Hmm, but if a user bulk inserts several rows at once, many of them could get the same datetime value (at least if we're talking about std datetime accuracy to...
February 24, 2009 at 4:05 pm
I agree; one single, keyed INSERT should not take that long.
(As an aside, though, that is a fairly long row (in bytes). If you do not update rows after...
February 24, 2009 at 3:59 pm
--CREATE VIEW viewname AS
COALESCE(sel.id, defaults.id) AS Id,
COALESCE(sel.name, defaults.name) AS Name
SELECT 10 AS id, 'NotAvail' AS Name
February 3, 2009 at 12:55 pm
I was reading the textual plan, not the graphical one, which at a quick look I thought was using IX_sysValidationList index.
January 29, 2009 at 1:13 pm
If you look at the exec plan, you'll notice it's a table scan on the lookup, not an index seek.
I never said it was doing a seek, I said it...
January 29, 2009 at 8:21 am
Hmm, so a given item can't go to a different status *and back* on sequential weeks:
SELECT 'B100', 1, 'FFF', 1, '2009-04-04 00:00:00.000', '2009-04-10 00:00:00.000', 0 UNION ALL
SELECT 'B100', 1, 'FFF',...
January 27, 2009 at 3:53 pm
In addition to the other suggestions, make sure that:
1) Join columns are indexed
2) Indexes have the proper freespace and are reorganized / rebuilt as often as needed to keep them...
January 27, 2009 at 3:31 pm
It looks to me like SQL is using the non-clus index on the lookup table. It scans it once for each LOJ, building a hash table to match to...
January 27, 2009 at 3:22 pm
select * from @tbl1 tbl1 join @tbl2 tbl2 on tbl1.VersionUsed+tbl1.QID = tbl2.VerOriginal+tbl2.QID
I agree about avoiding the concatenation. And it's definitely not needed here anyway:
FROM @tbl1 tbl1
January 27, 2009 at 2:35 pm
Add this column:
as an INCLUDEd column to your existing index.
Otherwise, the query plan looks reasonable.
It would be better if you didn't convert for the sort, but you will get...
January 27, 2009 at 1:53 pm