Viewing 15 posts - 57,466 through 57,480 (of 59,067 total)
Ugh! Correlated Sub-Queries = Instant RBAR. Not good... real performance killer. Should be a derived table. WHERE IN... not good... should be an equi-join (inner join).
Haven't tested it but I'm...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2006 at 5:21 pm
I don't use debuggers in SQL Server... just the ol' Mil Spec Mark I Mod I Eyeball. Probably not what you wanted to hear, though...
What are you trying to debug...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2006 at 4:57 pm
I loved the examples... nice and simple. Great job, DC.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2006 at 11:59 am
Yep... this is about 3 times faster (I tested both)...
CREATE FUNCTION dbo.GetDOWCount
(
@StartDate DATETIME,
@EndDate DATETIME,
@DOW VARCHAR(9) --Monday, Tuesday, Wednesday, etc
)
RETURNS INT
AS
BEGIN
RETURN (SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 7, 2006 at 8:11 pm
Actually, a function would slow stuff down here... you want the full table to be split... why do it a line at a time? Try this, instead...
--==================================================================================================
-- This...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 7, 2006 at 6:41 pm
For what? Inserts, Updates, Deletes, or Selects?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 7, 2006 at 6:16 pm
Try something like this, instead...
SELECT
locationId, locationId AS original_locationId, locationCode, description, divisionCode, companyId
FROM locations
ORDER BY companyId,
CASE
WHEN locationCode NOT LIKE '%[^0-9]%' THEN STR(locationcode,10)
ELSE locationcode
END,
locationCode
--Jeff Moden
Change is inevitable... Change for the better is not.
October 7, 2006 at 6:08 pm
ISNUMERIC does NOT mean IS ALL DIGITS... you're making a BIG mistake using it for that. If you don't think so, try this...
SELECT NULL AS [ASCII#],'12D45' AS [Character(s)],ISNUMERIC('12D45')...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 7, 2006 at 5:57 pm
Heh, heh, heh.... leave it to Serqiy to just say it like it is
Splitting the tables like this is, in fact,...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 7, 2006 at 10:03 am
Fabiano,
Ok... that's about 40 characters per select including the UNION ALL... that's only 100 tables if you use VARCHAR(4000) or NVARCHAR(4000). So, use VARCHAR(8000) and just use EXEC... don't use...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 6, 2006 at 8:04 pm
Just a note folks... anytime you use a column name in a formula in the WHERE or ON clause of a SELECT, you make it impossible for the coveted INDEX...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 6, 2006 at 6:37 am
Serqiy beat me to it! STOP USING SYSTEM TABLES FOR SUCH SIMPLE CHECKS!!! Use the system functions like Serqiy did.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 5, 2006 at 5:52 pm
Oh... no, no, no, no... ISNUMERIC does not adequately test for IS A NUMBER or IS ALL DIGITS...
Try this...
SELECT ISNUMERIC('$1,000')
SELECT CAST('$1,000' AS MONEY)
SELECT CAST('$1,000' AS INT)
GO
SELECT ISNUMERIC('0d05')
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 5, 2006 at 5:44 pm
Fabiano,
What is the pattern of you table names? And are they in the same database or different databases? I have the same problem with some 3rd party software at work...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 5, 2006 at 5:32 pm
You did all the hard work... I think this is probably what you're looking for... the changes will group your output by date and hour...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 5, 2006 at 7:10 am
Viewing 15 posts - 57,466 through 57,480 (of 59,067 total)