One way this could happen is if the inclusion of other columns changed the query plan in just the right way.

Imagine that all the rows in the table that...

Eirikur Eiriksson (5/14/2016)

---

What do you mean by this?

😎

Date is obviously better than int or char but the OP was exactly on those...

+1.

I couldn't resist, so I added a DATE column and a query that pulled that to the date_bucket (not being...

Lynn Pettis (5/13/2016)

---

Could some someone provide me with some UNICODE string data that casts wrong from NVARCHAR to VARCHAR and back? Don't need a lot, just a few short...

The trick here seems to be that while joining two tables is sufficient to prevent SQL Server from propagating the identity property, it really does have to be two tables.

From...

That's a bit of a rough situation.

One other option would be to grab the plan_handle of the proc when it's performing poorly, and run a DBCC FREEPROCCACHE, passing in that...

sys.sql_modules will also have view definitions.

You'd just need to join to sys.views instead.

I'd actually prefer just joining to sys.objects. You can then just filter to whatever object type or...

As far as I know, the only reason this would happen is if you're connected to a pre-2005 version of SQL Server.

I'd double-check that you're actually connected to a 2012...

In the posted .sqlplan files, the reason the slower plan is slower is pretty clear.

If you look at the actual remote query being run, the faster plan is sending over...

Wayne West (5/10/2016)

---

I found it very interesting reading up on Vardecimal. The systems that I typically use rarely use decimal, much less a large number of such fields that...

Maybe something like this?

SELECT month_end,

v.[Prop Code],

v.[History Ind],

...

As others have pointed out, there is no spoon (with spoon being the fictitious vardecimal data type, of course).

I thought going that route seemed a bit easy, but oh well,...

Or this thread you were in http://www.sqlservercentral.com/Forums/FindPost1292860.aspx 🙂

At any rate, as pointed out in both places, the main thing is that it's easier to get the function behaving the way...

Luis Cazares (5/9/2016)

---

Something shorter, not sure if that means better. 😀

SELECT current_value=some_bigint,

next_place_value=POWER(10,CAST(LOG10(some_bigint) AS INT)+1),

next_place_value=POWER(10,LEN(some_bigint))

FROM ...

Something like this?

CREATE TABLE #bigints (some_bigint bigint);

INSERT INTO #bigints VALUES

(129995),

(5000),

(100),

(999100876);

SELECT current_value=some_bigint,

next_place_value=POWER(10,CAST(LOG10(some_bigint) AS INT)+1)

FROM #bigints;

Cheers!