Viewing 15 posts - 4,411 through 4,425 (of 7,610 total)
SELECT
r.ID, r.FULL_NAME, r.FULL_ADDRESS,r.MEMBER_TYPE, r.BIRTH_DATE,
CONVERT (int,DATEDIFF(hour,r.BIRTH_DATE,GETDATE())/8766)as Age,r.MEETING_TYPE,r.MEETING,r.TITLE,
r.Parent1_FullName,r.Parent1_Cell,r.Parent1_Email,
r.Parent2_FullName,r.Parent2_Cell,r.Parent2_Email
FROM (
SELECT r2.ID
FROM IMIS.dbo.vw_csys_registrations r2
WHERE r2.MEETING_TYPE in ('PADA', 'TSM') AND r2.MEMBER_TYPE LIKE...
February 23, 2016 at 3:40 pm
I think this will identity whether or not a row exist and will probably run much more quickly, since no massive join is involved, although a huge sort will be...
February 23, 2016 at 3:30 pm
hlsc1983 (2/23/2016)
February 23, 2016 at 1:39 pm
Below is a more fully sketched out design. Hopefully this is not a homework or project assignment :-D.
CREATE TABLE dbo.subjects (
subject_id int IDENTITY(1, 1)
...
February 23, 2016 at 11:34 am
Worse, all this query tuning is likely effectively wasted anyway since the clus index is not being correct first. As soon as another column is added to this...
February 23, 2016 at 10:46 am
I think you should get check all NULLable columns for a given table in a single pass. It could hurt severely hurt performance to have to scan the same...
February 22, 2016 at 10:36 am
Hugo Kornelis (2/19/2016)
ScottPletcher (2/19/2016)
Log tables are almost always best clustered on a datetime, and virtually never on an identity value.
When it's an insert datetime, I think that this guess would...
February 19, 2016 at 9:56 am
Hugo Kornelis (2/19/2016)
ScottPletcher (2/19/2016)
You should cluster this table on upsrt_dttm instead.
How can you possibly determine that this should be a good clustering key based on seeing only one single query...
February 19, 2016 at 9:24 am
The "standard" performance problem when clustering on an identity column "by default". Trying to work around the wrong clustered index will generate lots of extra I/O.
You should cluster this...
February 19, 2016 at 9:15 am
Make sure the sub-procs have their own CATCH blocks. You can use empty/dummy blocks if you don't care about errors there:
CREATE PROCEDURE sub_proc
AS
...
BEGIN CATCH
--ignore error here
END CATCH
February 17, 2016 at 3:51 pm
Try the RECOMPILE option. That time will be trivial compared to I/O time.
Also, do review the indexes on the table: getting the best clustered index on every table is...
February 17, 2016 at 3:49 pm
In theory you could:
SET ANSI_WARNINGS OFF
But read up very, very carefully on that before you do it!
Or, you could create a stored proc and pass the values into the proc...
February 17, 2016 at 3:45 pm
Yes.
The first query only considers rows where [LotJob] = '0000337495'.
The second first gets the max LotJob and then that max value must be = '0000337495' for the row...
February 17, 2016 at 9:31 am
Hugo Kornelis (2/16/2016)
ScottPletcher (2/16/2016)
Get rid of the dashes (-) in the date, they introduce errors (ambiguity).Use format 'YYYYMMDD [hh:mm:ss]', which is always interpreted correctly, regardless of language/date settings.
Sorry, but that...
February 16, 2016 at 1:26 pm
Sounds like a good way to get yet more of the dreaded:
String or binary data would be truncated.
error. MS, seriously, you can't tell us which column had the error??...
February 16, 2016 at 1:18 pm
Viewing 15 posts - 4,411 through 4,425 (of 7,610 total)