Viewing 15 posts - 661 through 675 (of 1,554 total)
Apparently there is a designproblem here...
Could you expand on the purpose of this excercise? Perhaps with a complete example that demonstrates the behaviour you're looking for?
/Kenneth
January 13, 2006 at 7:43 am
Not necessarily equal..?
c.key isn't part of the join definition, as far as we know there may be c.key containing both null and non-values. If conditions where c.id = t.currencyID is...
January 13, 2006 at 5:07 am
Anytime you come across the number 255 or 256 you should be suspicious of configs and settings, since this is the 'old DOS' max-limit for many things.
January 12, 2006 at 9:14 am
What does the execution plan look like?
Things to not want from an optimization perspective (but still may be necessary)
DISTINCT - sort is negative on performance
NOT - negations may force scans...
January 12, 2006 at 9:09 am
Would this be of any help?
http://www.codecomments.com/archive342-2005-10-638192.html
(Google to the rescue)
/Kenneth
January 12, 2006 at 8:53 am
Umm.. this seems a bit vague..
If Col1 and value 10 gets ID 1, why does Col2 and value 11 get ID 2...? Shouldn't it also get ID 1?
Anyway, your true...
January 12, 2006 at 8:44 am
Umm... if this is something that is in development, then changes to the code involved is expected to a certain point.
If you're considering using procedures 'later', you really should start...
January 12, 2006 at 3:10 am
One solution is to perform a detailed application code review to make sure no implicit data type conversions are used, strings are compared to strings and integers to integers.
Regardless of evironment,...
January 12, 2006 at 2:38 am
Could you post a small sample of the tExpLic table (and other tables if they are important) with a few rows of sample data that reperesents the nature of the...
January 11, 2006 at 2:49 am
Well, not necessarily. It depends.
Given enough complexity and/or large enough tables a view may yield less performance than a 'pure statement'. When joining between views this risk can also become...
January 9, 2006 at 2:23 am
Not sure any indexes is going to do much good.
The query is a join without further filtering, which means you'll have to scan both tables anyway since the requested result is...
January 5, 2006 at 3:55 am
It seems like the update may involve changes to more than one basetable? ie columns both the 'main' table and also in the basetable from where the derived column comes.
Perhaps...
January 5, 2006 at 3:41 am
What is your reason for the view in the first place? The most common reasons are to use views as a security layer and/or as containers for complex code.
It's common...
January 4, 2006 at 8:43 am
I think you're on the right track
If we disregard such things as to have temptables or not and other 'techie' stuff, you just...
January 3, 2006 at 7:41 am
But you do have each reps items in a table? So... begin the loop, while in the loop for each rep:
- grab the mailaddress
- select the list pertinent to that...
January 2, 2006 at 8:03 am
Viewing 15 posts - 661 through 675 (of 1,554 total)