Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

Column length Expand / Collapse
Author
Message
Posted Friday, April 9, 2010 3:49 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 7:19 PM
Points: 8,684, Visits: 9,214
Paul White NZ (4/8/2010)

I see nothing wrong with the original explanation. It correctly conveys the reason that the result is 'IsUnk' and not 'IsUnknown'.

I have to disagree. What you are telling me is that the length of the check expression is 5. That is pure nonsense.

The check_expression here is the result of applying LEFT(..., 5) to a VARCHAR(50) NULLable column. The type of check_expression is clearly VARCHAR(5) NULLable. The replacement_value is implicitly converted to that type, resulting in truncation - exactly what the explanation conveys.

Yes that's what is happening (except that I would take issue with the word "clearly", see below) . The explanation completely fails to convey that, it says something completely different is happening. It does give a pointer to part of the correct explanation.

[
What is interesting here is that left(X,5) delivers an expression of type varchar(5), not an expression of the same type as X. I haven't seen that documented anywhere, and I'm flabbergasted by it. Needless to say I got the wrong answer, and I've learnt this crazy behaviour of Left from it. I guess that makes it a good question - anything that makes me learn is good from my point of view.

LEFT is documented as returning (n)varchar...what is it exactly that baffles you about an expression with a defined maximum length of 5 being returned as (n)varchar(5)?

From Expressions (Transact-SQL): When two expressions are combined by using arithmetic, bitwise, or string operators, the operator determines the resulting data type.[/quote]

On that logic I could say what's wrong with * (or + or -) returning bigint when it needs to, instead of an error. But in fact
declare @x int = 214735276, @y int = 1073741827
select @x*@y

doesn't return 230570247573589252 which on your logic it ought to return: what would baffle you about a multiplication which returns a number between 2**62 and 2**64 returning a bigint, as it's obvious from the parameters that it won't fit a smaller type? But in that case the design decision was to return an error, and I guess you agree with it despite your interpretation of that "the operator determines the type" statement. In the case of left the decision was to make an arbitrary type change depending on the parameters - there's no consistency there, and cetrainly no clarity.

It would be nice if this case where an arbitrary type change is made were documented, but as far as I can tell it isn't.

None of that of course detracts from it being a good question with a correct answer. But I still think the explanation is wrong - it would have been improved by a change to say simply "see <BOL reference>" without the incorrect statement that actually precedes that.


Tom
Post #900294
Posted Friday, April 9, 2010 4:42 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 10:26 AM
Points: 11,194, Visits: 11,136
Tom.Thomson (4/9/2010)
I have to disagree. What you are telling me is that the length of the check expression is 5. That is pure nonsense.

The type of the check expression is VARCHAR(5) NULLable. It has a maximum length of 5. What is nonsensical or even slightly hard to understand about that?

The explanation completely fails to convey that, it says something completely different is happening. It does give a pointer to part of the correct explanation.

No. It conveys the crucial point without being verbose.

On that logic I could say what's wrong with * (or + or -) returning bigint when it needs to, instead of an error.

If you look up the multiply operator in Books Online, you will see that it "Returns the data type of the argument with the higher precedence". Decided by the operator, as I said before.

In the case of left the decision was to make an arbitrary type change depending on the parameters - there's no consistency there, and cetrainly no clarity.

It's clear and consistent - it is decided by the operator. Try it with other functions, computed columns, SELECT...INTO, parameterization, and so on and so on. All work the same, consistent and clear.

It would be nice if this case where an arbitrary type change is made were documented, but as far as I can tell it isn't.

I can only suggest you keep looking - most behaviour is documented in Books Online in detail.

...I still think the explanation is wrong - it would have been improved by a change to say simply "see <BOL reference>" without the incorrect statement that actually precedes that.

The vast majority of people are looking for a 'bite-sized' explanation - not just a lazy link to BOL. The lack other people in this thread whining about any perceived inadequacies in the 'bite-sized' answer seems to indicate that your view is in the minority.




Paul White
SQL Server MVP
SQLblog.com
@SQL_Kiwi
Post #900340
Posted Friday, April 9, 2010 10:26 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 7:19 PM
Points: 8,684, Visits: 9,214
Paul White NZ (4/9/2010)
Tom.Thomson (4/9/2010)
I have to disagree. What you are telling me is that the length of the check expression is 5. That is pure nonsense.

The type of the check expression is VARCHAR(5) NULLable. It has a maximum length of 5. What is nonsensical or even slightly hard to understand about that?


There is nothing nonsensical or hard to understand about what you are saying there. What is nonsense is your previous statement that the explanation says this. It doesn't. The explanation says that the result is truncated to the length of the check expression (implying that the length of NULL is 5 here). That is NOT remotely the same thing. Why do you want to claim it is?

I'll skip most of the rest of your comment, because anything I said would be much the same as before, so pointless repetition: a waste of space; but on a couple of things it may be worthwile to say something.

It would be nice if this case where an arbitrary type change is made were documented, but as far as I can tell it isn't.

I can only suggest you keep looking - most behaviour is documented in Books Online in detail.
The best you've offered is a pointer to the general statements that functions determine the results of their results. That doesn't actually tell me a single thing about what left determines as the type of its result. I'm pretty sure that this is NOT documented in BoL - sure enough that I'll waste no more time looking for it. It's quite clear from its behaviour on a few test cases that it makes no use any type information available for its first argument other than to place an upper bound on the length component of the type of a NULL and to determine whether the character component is char or nchar, so what do I need documentation for? Oh, it might change in the next release if it's not documented - well, hard luck me).

...I still think the explanation is wrong - it would have been improved by a change to say simply "see <BOL reference>" without the incorrect statement that actually precedes that.

The vast majority of people are looking for a 'bite-sized' explanation - not just a lazy link to BOL. The lack other people in this thread whining about any perceived inadequacies in the 'bite-sized' answer seems to indicate that your view is in the minority.
[/quote]
Clever piece of selective quoting there, sir, a nice "..." conceals the words that make nonsense of your remark about whining about the answer by stating clearly and unambiguously that the answer is correct. You know perfectly well that this discussion has nothing to do with the answer, but concerns the explanation. Why pretend it has?

As to number of people, we first have abrar asking for more explanation (which is part of why I commented - and his reply to my comment suggests he found it useful) and sknox saying he thinks the explanation is inadequate and making much the same points as me in a looser style. So that's 3 people on one side. On the other side we have one liners from Jason and Ramchandra, a two-liner from yoursel (quibbling that the absence of a NOT NULL constraint was not explicitly declared - now that really is whining about nothing, isn't it) and a comment from dbowlin. That's 4 people. We don't have the usual collection of whiners claiming it's not fair they didn't get their point, because there is nothing anyone could hang such a claim on - as I said before, the question is clear and unambiguous and the answer is correct. So it's 3:4 - not a startling majority either way, is it? Or is that a grey area that you want to claim is white?

My comments are fourfold:
(i) I chose the wrong answer (not because there's anything wrong with the question but because I didn't know that the type of the result of left(cast(null as varchar(50)),5) is varchar(5) - I should have known, but I didn't).
(ii) It's a good clear question with a good correct answer.
(iii) The explanation is incorrect (only the type of the check argument affects truncation of the result, not its length) and incomplete (no mention of the type of the result of the left function).
(iv) I find the behaviour of the left function surprising and consider it not consistent with the behaviours of arithmetic functions, which have the advantage of being well documented.
Do you actually disagree with any of these, or are you just having fun?


Tom
Post #900699
Posted Friday, April 9, 2010 9:42 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 10:26 AM
Points: 11,194, Visits: 11,136
Tom.Thomson (4/9/2010)
What is nonsense is your previous statement that the explanation says this. It doesn't. The explanation says that the result is truncated to the length of the check expression (implying that the length of NULL is 5 here). That is NOT remotely the same thing.

Good grief, man!

The explanation says "the IsNull() function will truncate the length of replacement_value to that of check_expression." The check_expression has a type of VARCHAR(5). The replacement_value has an implied type of VARCHAR(9). Many people taking the question would expect the result to be 'IsUnknown', and would be surprised that it was 'IsUnk'. This represents by far the majority of wrong answers - and, I would wager, was the main point of the question.

The explanation succinctly expresses the reason for the unexpected answer - the VARCHAR(9) is truncated to VARCHAR(5) by the ISNULL function. It really is as simple as that.

The fact that you, and the other 19% that selected the wrong answer, did not know this, simply means you have learnt something, which is the point of the QotD. Your point about 'the length of NULL' is irrelevant and shows your lack of understanding - not that of the questioner.

The best you've offered is a pointer to the general statements that functions determine the results of their results. That doesn't actually tell me a single thing about what left determines as the type of its result. I'm pretty sure that this is NOT documented in BoL - sure enough that I'll waste no more time looking for it.

I am not here to locate stuff in Books Online for you - if you want to expand your understanding, you will have to put some effort in. I would encourage you to look into how SQL Server determines the type of an expression in general - for computed columns, SELECT...INTO statements, parameterization, and so on. It is logical, consistent, and documented.

The explanation is incorrect (only the type of the check argument affects truncation of the result, not its length) and incomplete (no mention of the type of the result of the left function).

Are you saying the explanation is incorrect (as in all your previous statements) or that it is just incomplete now? You seem to be moving from absolute statements like 'nonsense', 'wrong' and 'incorrect' to something closer to 'well, technically, it might be more accurate to say...'

To avoid any danger of coming off as a tedious, overly-academic, pedant - and there is a risk - I would encourage you to accept the explanation for what it is: a simple statement. A QotD explanation is not required to explore ever possible nuance. In any case, the type of check_expression defines its maximum length.

I find the behaviour of the left function surprising and consider it not consistent with the behaviours of arithmetic functions, which have the advantage of being well documented.

I believe I have answered this already: The operator determines the type of the result, in all cases.
Your refusal to check the documentation disqualifies you from making absolute statements about what is, and is not, documented. You may find it surprising, you may consider it inconsistent, you may think it's wrong, nonsense or whatever. That doesn't make it so.




Paul White
SQL Server MVP
SQLblog.com
@SQL_Kiwi
Post #900950
Posted Friday, April 9, 2010 11:01 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 7:19 PM
Points: 8,684, Visits: 9,214
Paul White NZ (4/9/2010)
Tom.Thomson (4/9/2010)
What is nonsense is your previous statement that the explanation says this. It doesn't. The explanation says that the result is truncated to the length of the check expression (implying that the length of NULL is 5 here). That is NOT remotely the same thing.

Good grief, man!
That exactly matches my reaction to your comments!

The explanation says "the IsNull() function will truncate the length of replacement_value to that of check_expression." The check_expression has a type of VARCHAR(5). The replacement_value has an implied type of VARCHAR(9). Many people taking the question would expect the result to be 'IsUnknown', and would be surprised that it was 'IsUnk'. This represents by far the majority of wrong answers - and, I would wager, was the main point of the question.

The explanation succinctly expresses the reason for the unexpected answer - the VARCHAR(9) is truncated to VARCHAR(5) by the ISNULL function. It really is as simple as that.

The fact that you, and the other 19% that selected the wrong answer, did not know this, simply means you have learnt something, which is the point of the QotD. Your point about 'the length of NULL' is irrelevant and shows your lack of understanding - not that of the questioner.

I wish you would pay some attention to what I say instead of to what you want to pretend I said. I think my comments make it absolutely clear that I know perfectly well that IsNull truncates to the length embedded in the type of the check argument when the check argument is one of the character or binary types. Your claim that I don't understand that is just plain outrageous. The reason (as you well know, since it was there plainly and clearly in my original post, so I can only assume you are being deliberately inaccurate on this) that I got the wrong answer is that I thought the left function returned a value with the same type as its first argument.
The best you've offered is a pointer to the general statements that functions determine the results of their results. That doesn't actually tell me a single thing about what left determines as the type of its result. I'm pretty sure that this is NOT documented in BoL - sure enough that I'll waste no more time looking for it.

I am not here to locate stuff in Books Online for you - if you want to expand your understanding, you will have to put some effort in. I would encourage you to look into how SQL Server determines the type of an expression in general - for computed columns, SELECT...INTO statements, parameterization, and so on. It is logical, consistent, and documented.

I don't want you to locate that stuff for me - you'd have a job anyway, as it isn't there (at least google can't find it, nor bing, nor MSDNs own search).

The explanation is incorrect (only the type of the check argument affects truncation of the result, not its length) and incomplete (no mention of the type of the result of the left function).

Are you saying the explanation is incorrect (as in all your previous statements) or that it is just incomplete now? You seem to be moving from absolute statements like 'nonsense', 'wrong' and 'incorrect' to something closer to 'well, technically, it might be more accurate to say...'
I haven't changed what I'm saying. The explanation is incomplete. What there is of it is also incorrect, because it talks of LENGTH (meaningless since it has to apply to NULL, whose length is also NULL) instead of TYPE. How is that different from "incorrect and incomplete"? Are you suggesting that the length of the result is NULL (the LENGTH of the first argument) rather than 5 (the length embedded in the TYPEof the first argument)?

To avoid any danger of coming off as a tedious, overly-academic, pedant - and there is a risk - I would encourage you to accept the explanation for what it is: a simple statement. A QotD explanation is not required to explore ever possible nuance. In any case, the type of check_expression defines its maximum length.
Exactly. It is the TYPE that is at issue. It can hardly be the LENGTH of an expression whose value is NULL, can it? It really irritates me that you keep on insisting that "LENGTH" is correct and that I'm wrong or pedantic (that does seem to be a bit of a retraction from wrong though, doesn't it) to say that it's the TYPE that matters, since you clearly do understand full well that it's the TYPE (and the length that is embedded in that TYPE) not the LENGTH of the argument that counts.

I find the behaviour of the left function surprising and consider it not consistent with the behaviours of arithmetic functions, which have the advantage of being well documented.

I believe I have answered this already: The operator determines the type of the result, in all cases.
As I have pointed out before, that is not an answer. It is a tautology that a function determines the type of its result. That doesn't tell anyone, for any particular function, what that type is for given arguments - that needs to be specified.
Your refusal to check the documentation disqualifies you from making absolute statements about what is, and is not, documented. You may find it surprising, you may consider it inconsistent, you may think it's wrong, nonsense or whatever. That doesn't make it so.

And you may believe it is documented: that does not make it so either. I've done a pretty thorough search of the documentation, using tools that I would expext to find the definition of how left determines the result TYPE ( as opposed to the result LENGTH for non-null cases) if such a definition were present - and it has turned up nothing, so I have good grounds to believe it is not documented. That's not a refusal to check the documentation - it's the result of a very thorough check - more thorough than you've undertaken, I suspect, since you are unable to provide any reference that supports your claim that the type of the LEFT functions result is documented. You continue to assert that the definition is there, but refuse to give a reference. Well, why should I believe you when you present no evidence?


Tom
Post #900994
Posted Saturday, April 10, 2010 1:23 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 10:26 AM
Points: 11,194, Visits: 11,136
Tom.Thomson (4/9/2010)
I wish you would pay some attention..blah...blah..blah..

No. You failed to answer correctly because you made an incorrect assumption, based on incomplete knowledge. Attempting to wriggle and back-track to somehow blame the explanation is very poor form.

Your rambling and border-line incoherent response above completely fails to address the text you quoted: The explanation perfectly adequately explains why IsUnknown becomes IsUnk. Your whole difficulty arises from an incorrect inference to the meaning of the word 'length' in that explanation. Your view relies on length being applied to the value of numdesc inside the check_expression, as opposed to the maximum length of the type returned by LEFT. No doubt you would prefer the following:

"the IsNull() function will truncate the length of replacement_value to the typed length of check_expression."

And that is precisely the distinction that I regard as pedantic, overly-academic, picky, and ultimately tedious. This is a Question of the Day, not a paper - and your lack of flexibility does you no credit.

I haven't changed what I'm saying. The explanation is incomplete.

You said it was wrong. Now you say it is incomplete. Back-tracking and wriggling.

Are you suggesting that the length of the result is NULL (the LENGTH of the first argument) rather than 5 (the length embedded in the TYPEof the first argument)?

No - whatever gives you that idea? That was your assertion in your first post: "The length of left(null,5) is not 5, it is null." - though it's not clear whether you mean the length of NULL is NULL (a tautology) or that the enclosing type would have a NULL length (which is wrong).

...that does seem to be a bit of a retraction from wrong though, doesn't it

Yes. Makes it hard to keep track of what your current position is.

...I have good grounds to believe it is not documented...more thorough than you've undertaken, I suspect

It doesn't exist because you can't find it?
And you are claiming to be psychic now as well? I have not said that it definitely is documented - just that most behaviour is. Read back, and try to respond to what I actually said, rather than what you would like me to have said

Let's be clear about this: I do not care why you got this question wrong. What I do object to is your over-use of strong words like 'nonsense', 'wrong', 'crazy', and 'arbitrary'. It seems as if you think (or hope) others will not question your remarks if you present them as fact using sufficiently over-blown language.

If you think it makes you look smart to be an arch-pedant over the wording of the explanation to a QotD...think again.




Paul White
SQL Server MVP
SQLblog.com
@SQL_Kiwi
Post #901021
Posted Saturday, April 10, 2010 11:27 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 7:19 PM
Points: 8,684, Visits: 9,214
Paul White NZ (4/10/2010)
Tom.Thomson (4/9/2010)
I wish you would pay some attention..blah...blah..blah..

No. You failed to answer correctly because you made an incorrect assumption, based on incomplete knowledge. Attempting to wriggle and back-track to somehow blame the explanation is very poor form.

Your rambling and border-line incoherent response above completely fails to address the text you quoted: The explanation perfectly adequately explains why IsUnknown becomes IsUnk. Your whole difficulty arises from an incorrect inference to the meaning of the word 'length' in that explanation. Your view relies on length being applied to the value of numdesc inside the check_expression, as opposed to the maximum length of the type returned by LEFT. No doubt you would prefer the following:

"the IsNull() function will truncate the length of replacement_value to the typed length of check_expression."
yes, that would be an improvement.
And that is precisely the distinction that I regard as pedantic, overly-academic, picky, and ultimately tedious. This is a Question of the Day, not a paper - and your lack of flexibility does you no credit.

I haven't changed what I'm saying. The explanation is incomplete.

You said it was wrong. Now you say it is incomplete. Back-tracking and wriggling.
More clever selective quoting. The line you quote a fragment of is actually
The explanation is incomplete. What there is of it is also incorrect

I, and probably most civilised people regard that sort of deliberate selection of part of a statement to give the impression that something was said that clearly was not said as dishonest and disgraceful. I have said that it is incomplete and incorrect consistently throughout.

...that does seem to be a bit of a retraction from wrong though, doesn't it

Yes. Makes it hard to keep track of what your current position is.

What? You are trying to say that when you change from saying "wrong" to saying "pedantic" that's me changing my position? That's pure drivel. Your position changed, not mind - I agree with neither your original "wrong" nor your later "pedantic".

...I have good grounds to believe it is not documented...more thorough than you've undertaken, I suspect

It doesn't exist because you can't find it?
And you are claiming to be psychic now as well? I have not said that it definitely is documented - just that most behaviour is. Read back, and try to respond to what I actually said, rather than what you would like me to have said
[/quote] No I'm not psychic? Where did you pick up that nonsense from? The point you would do well to understand is that if you insist on saying "most behaviour is documented" as if it were an answer to the question whether this particular behaviour is documented you are being downright unhelpful.
Let's be clear about this: I do not care why you got this question wrong. What I do object to is your over-use of strong words like 'nonsense', 'wrong', 'crazy', and 'arbitrary'.

And after this exchange, I don't care what you object to.

It seems as if you think (or hope) others will not question your remarks if you present them as fact using sufficiently over-blown language.

If you think it makes you look smart to be an arch-pedant over the wording of the explanation to a QotD...think again.

If you think it makes you look smart to use the tricks of selective quotation and attributing to people things they have no said that are normally associated with the depths of gutter journalism, then you need to think again.


Tom
Post #901104
Posted Saturday, April 10, 2010 9:09 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 10:26 AM
Points: 11,194, Visits: 11,136
Tom.Thomson (4/10/2010)
yes, that would be an improvement.

Then that is all that needed saying. You chose to make the bald statement "This explanation is wrong." - and then ramble on for pages, dodging and weaving, back-tracking, and wriggling to turn it into "incomplete". Laughable.

Sknox put it better in the post previous to your first one, "This explanation feels a little light. For completeness, it should include the behavior of the LEFT() function as well."

I don't know what you think your input added to that.

I, and probably most civilised people regard that sort of deliberate selection of part of a statement to give the impression that something was said that clearly was not said

I have tried to be fair and extract the salient points from your verbose replies. Not my fault if you can't express yourself clearly.

For the record, I haven't changed my position one iota.




Paul White
SQL Server MVP
SQLblog.com
@SQL_Kiwi
Post #901175
Posted Sunday, April 11, 2010 6:01 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 7:19 PM
Points: 8,684, Visits: 9,214
Paul White NZ (4/10/2010)
Tom.Thomson (4/10/2010)
yes, that would be an improvement.

Then that is all that needed saying. You chose to make the bald statement "This explanation is wrong." - and then ramble on for pages, dodging and weaving, back-tracking, and wriggling to turn it into "incomplete". Laughable.

You continue to distort - clearly quite deliberately. Can you tell me how "it's incomplete. What there is of it is incorrect" means "not incorrect", how it means "incomplete" alone and doesn't suggest "incorrect"? Or even how it is unclear?

Sknox put it better in the post previous to your first one, "This explanation feels a little light. For completeness, it should include the behavior of the LEFT() function as well."

I don't know what you think your input added to that.

The person who had asked for more explanation appeared to like it. That matters more to my than all your venemous ranting,

I, and probably most civilised people regard that sort of deliberate selection of part of a statement to give the impression that something was said that clearly was not said

I have tried to be fair and extract the salient points from your verbose replies. Not my fault if you can't express yourself clearly.

So you continue to distort. I think the statement you mangled was clear, and you deliberately chose to truncate it to give the impression that I had said something which I clearly diod not say.


For the record, I haven't changed my position one iota.

Then why did you say that your change from "wrong" to "pedantic" was a change in position?


Tom
Post #901219
Posted Sunday, April 11, 2010 8:40 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 10:26 AM
Points: 11,194, Visits: 11,136
Tom.Thomson (4/11/2010)
You continue to distort - clearly quite deliberately.

Psychic Tom strikes again! Not only did you "know" how much documentation I had checked earlier, you now "know" that I am 'quite clearly' distorting your words! How do you know that? Why would I do that? What would be my motivation? If you really want to know, I find your replies hard work: they are too long, and you do not communicate at all clearly. I don't have all day to try to decode what you write, you know.

Can you tell me how "it's incomplete. What there is of it is incorrect" means "not incorrect", how it means "incomplete" alone and doesn't suggest "incorrect"? Or even how it is unclear?

Yes Tom, I can. It is an unclear and bizarre construction. I'm not sure even you know what you mean here. Is it merely incomplete? Or is it incorrect? I don't know why you insist on writing two awkward sentences when a couple of words will do, really I don't. Do you do it intentionally?

The person who had asked for more explanation appeared to like it. That matters more to my than all your venemous ranting

Well, that's rich! I would invite you to read your own submissions before casting aspersions.

I, and probably most civilised people regard that sort of deliberate selection of part of a statement to give the impression that something was said that clearly was not said

Hmmm...civilised might be a bit strong, given your performance here. Look, I've already said that I have tried to be fair when quoting. Your responses are just far too long to quote in their entirety. If you feel you have been misquoted, I would invite you to consider whether that was really done deliberately and maliciously - or whether perhaps you might have been less than clear?

So you continue to distort.

All I said was that I tried to be fair, and you don't express yourself well. That is my genuine perception, and even 'psychic Tom' can't argue with that.

I think the statement you mangled was clear, and you deliberately chose to truncate it to give the impression that I had said something which I clearly diod not say.

No, Tom. You presume far too much. Your statement was not clear at all. I did not truncate it to misrepresent what I read.

Then why did you say that your change from "wrong" to "pedantic" was a change in position?

I didn't - I thought you were referring to yourself in the following (complete) passage:

Exactly. It is the TYPE that is at issue. It can hardly be the LENGTH of an expression whose value is NULL, can it? It really irritates me that you keep on insisting that "LENGTH" is correct and that I'm wrong or pedantic (that does seem to be a bit of a retraction from wrong though, doesn't it) to say that it's the TYPE that matters, since you clearly do understand full well that it's the TYPE (and the length that is embedded in that TYPE) not the LENGTH of the argument that counts.





Paul White
SQL Server MVP
SQLblog.com
@SQL_Kiwi
Post #901228
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse