Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 158 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates


After some experimenting, I have now determined that the issue is not the number 200 per se, if >= 200 is used, the error does not occur.

I cloned the rank and percentile query on data.SE and then replaced the 100 with 200 and got the following:

Error: Operand type clash: uniqueidentifier is incompatible with int

The strange part is that 199 and 201 both work fine, so there is some problem with the > 200 in that query.

(For reference, this is the query which broke (it seems changing the UserId does not effect the outcome):

-- StackOverflow Rank and Percentile

WITH Rankings AS (
FROM Users
,Counts AS (
FROM Users
WHERE Reputation > 200
SELECT Id, Ranking, CAST(Ranking AS decimal(10, 5)) / (SELECT Count FROM Counts) AS Percentile
FROM Rankings
WHERE Id = ##UserId##​


OS: Win 7 32 bit Browser: 14.0.835.202 m

A screenshot: screenshot of error

share|improve this question
Hmm. Works for me with my user ID and yours – Michael Mrozek Oct 6 '11 at 14:27
Whoops, this was my bad...fixing. – Tim Stone Oct 6 '11 at 14:31
@TimStone Just curious, but what happened? – cwallenpoole Oct 6 '11 at 14:33
I think there's another underlying issue here, but an update I made to a query that optionally runs when you hit Run Query now has the query ID being used where the query hash was expected, which fails because they aren't the same data type (int versus uniqueidentifier). – Tim Stone Oct 6 '11 at 14:40
@TimStone Not that it really matters, but I really would be fascinated to learn how that happens. Unique bugs are interesting! – cwallenpoole Oct 6 '11 at 14:41
up vote 5 down vote accepted

This has been fixed now. Thanks to Rebecca Chernoff for pushing and building the updates.

You were seeing this error because I recently pushed out a change that attempted to update a query record in the database based on the query's hash, but inadvertently using the query's ID as input. Since one is a GUID and the other an int, that failed miserably when the update was executed.

That update is only executed if the query you're running was previously saved in the database, so it's just coincidental that the same query had been run before using the 200 value, and with minor alterations that made the system think that there were changes to be saved when you submitted it.

Ideally, the system shouldn't have been attempting to save those changes at all, but we'll need to rework the data model before we're able to address that issue. For now though, everything should work correctly again, so happy querying!

share|improve this answer
So cool! Thanks for the info! – cwallenpoole Oct 7 '11 at 3:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .