Speed of Stored Procedure


Author
Message
Bill Cunnien
Bill Cunnien
StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)
Group: Forum Members
Posts: 785, Visits: 3.6K
I am not getting it.  Earlier this spring I discussed in these forums the utilization of UDFs in filling a BO.  The conclusion was to not use them since they have a great deal of overhead involved.  So, instead, I went with some raw SQL to achieve the same results.  I was able to get one of my more complex queries down to about 3 seconds.  That was wonderful.  Now, I am simply taking the same script that runs in the SQL Query Analyzer at 3 seconds and placing it into a stored procedure with three parameters.  These parameters are declared at the beginning of the script in the query analyzer, too.  I run the stored procedure and it takes many minutes to run (last run: 10 min 04 sec).  I really don't get this.  It is the exact same script.  Is there really that much of a difference in quality between raw SQL script and the same SQL script placed into a stored procedure?  What am I doing wrong?  I have attached the script that I am running in the Query Analyzer and the stored procedure.  I know that these are not pretty...I am still working through the details of this query.  Any help, tips, criticism is welcome! Smile

Thanks,
Bill

Attachments
Running Inventory - Material.zip (128 views, 900 bytes)
Replies
Bill Cunnien
Bill Cunnien
StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)
Group: Forum Members
Posts: 785, Visits: 3.6K
The stored procedure does not like the LIKE.

Who woulda thunk it?!?!?!

I have removed the LIKE and have followed another approach:

IF @itemcode = ''
    BEGIN
        'run script without the Items.Code filter
    END
ELSE
    BEGIN
        'run the script with the Items.Code = 'MyCode'
    END

Thanks, again, Greg!!
Bill

Greg McGuffey
Greg McGuffey
Strategic Support Team Member (4.8K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
I'm not quite sure why LIKE isn't...er...liked by SQL Server, but I do know enough to include that in my list of things to check out when a query is slow. BigGrin



Glad you got it working (faster).
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Threaded View
Threaded View
Bill Cunnien - 17 Years Ago
Greg McGuffey - 17 Years Ago
Bill Cunnien - 17 Years Ago
Bill Cunnien - 17 Years Ago
Bill Cunnien - 17 Years Ago
                         If I remove the first parameter (varchar(30)), then the stored...
Bill Cunnien - 17 Years Ago
                             OK, that is different. I understand why you are baffled.:blink:
...
Greg McGuffey - 17 Years Ago
                                 [quote]I'd see what replacing the LIKE in your where clause with an...
Bill Cunnien - 17 Years Ago
                                     The stored procedure does not like the LIKE. Who woulda thunk...
Bill Cunnien - 17 Years Ago
                                         I'm not quite sure why LIKE isn't...er...liked by SQL Server, but I do...
Greg McGuffey - 17 Years Ago
Peter Jones - 17 Years Ago
Trent L. Taylor - 17 Years Ago
Peter Jones - 17 Years Ago
Trent L. Taylor - 17 Years Ago
Peter Jones - 17 Years Ago

Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search