What happens if you get a cheeseburger that is 10% smaller that advertised, but the manager is telling you that it's really only 9.090909% smaller?
Is this case for a refund?
We eventually figured out the "problem" and rewrote some syntax.
However, there is still no explanation why the EXACT same query runs in 15 seconds vs. "never returns", on 2000 and 2005 respectively.
It seems that it locks up on 2005.
Hmmm, confusing... using the (val1 - val2/ val1) formula:
val1 = 10
val2 = 9
gives you 10% (which seems right)
val1 = 9
val2 = 10
gives you 11% (which seems really wrong!)
How can one avoid this complication? I suppose if you *always* use the larger value as Val1, you can avoid this.
Hi,
I need some SQL syntax to do the following:
Compare 2 integer values (from 2 different tables) and make sure that the values DO NOT DIFFER by more than 10%.
Not sure how to write this!
Thanks
I seem to have narrowed down the performance problem somewhat.
Seems to be tied to a "like" clause, e.g.
...
AND e.myCol LIKE CASE @myParam
WHEN '<All>' THEN '%'
ELSE @myParam END
If I specify NULL for @myParam, the query runs in 15 seconds. If I specifiy a value for @myParam...
Crud. I restored the db, dropped AND recreated all indexes for the tables that are used by the stored proc. I updated the statistics also.
NO DICE.
The queries run like mud on 2005.
And I was wrong about the service pack. We're on sp2.
I have NO idea why this is happening at this point. Has...
Ok, I will give it a try.
Haven't seen this problem before, though, and I've restored the db many times w/o rebuilding any indexes.
Most of the procs run faster on 2005, except for these really slow ones.
Anyways, I have 100's of tables. Do you have any recommendations on how one should drop...
what I meant was did you just backup and restore the DB from the old server to the new server?
Yes
also make sure that you have as many files for the tempdb as you have physical cores per CPU
??
I have 2 servers, one is 2000, the other is 2005, sp1. The databases are identical, because I am restoring the database from the 2000 server onto the 2005 server.
I am running some stored procs on both servers. They take about 30 seconds on 2000. However, on 2005, they are taking like over 15...
Not sure I understand this:
insert exec into a temp table and select into a variable from there
Not sure how I would do this in this case? I'm calling the stored proc inside a cursor multiple times, also. So there could be multiple outputs.
Never thought about this before. But I'm calling a stored proc from a stored proc. The inside proc returns a couple rows to the screen, like this:
This is the sp output...
NULL
I want to capture the first row (message) into a variable. How would I do this??
Thanks much
Hi,
I realize that I don't really understand how sp_addlinkedsrvlogin works.
If you have a local user that you want to be able to log on to a remote (linked) server, does that user also have to exist on the remote server?
Or if by using sp_addlinkedsrvlogin, does it enable the local user to...
Yes, there's already a PK on syid, cuid, and date.
Seems to be an issue with the self-join, from what I've seen in other posts.
The query is *extremely* complex in its entirely, but this part of the query uses up 100% of the execution cost.
Changing the join changes the result, unfortunately. And does not eliminate the index scans of hash match. They are still there, just in a different place.
Hi,
I have a part of a query that is quite expensive:
LEFT JOIN
myTable t1
ON t1.SyId = pos.SyId and t1.CuId = cu.CuId and t1.Date = @AsOfDate
LEFT JOIN
myTable t2
ON t2.SyId = pos.SyId and t2.CuId = cu.CuId and t2.Date = @StartDate-1
LEFT JOIN
myTable t3...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.