Have just been hitting these problems in SSIS with Visual Studio 2015.

Even though there is an 'Advanced Editor' which allows you to set the external datatypes to DT_NTEXT, this reverts...

Ok, I must admit, I've not seen such am alarming example of float mathematics going wrong before. This is kinda scary.

While I have your attention though... how do you get...

Well what is the "Why"? Why are floats not considered best practice by some?

I don't know what unnecessary work later is incurred by using floats, but I know of lots...

and by 'lazy' you mean??? Not doing unnecessary work?

This post explores one of the performance pitfalls you can get yourself into by introducing DRY principles with SQL server.

http://cubicmile.co.uk/2013/06/02/sql-code-re-use-a-worked-example/

Whilst I have found RedGate's SQLCompare tool useful for deploying schema changes in the past, the problem it has is that is a tool and will never be able deal...

Oh ok that makes sense.

This also explains why it WASN'T giving elevated permissions on tables in a different database. Which is why I started looking into this in the first...

You might want to ask them what the result of this query is:

Select *

from currency

where...

I'm sorry, but what?

I'm missing the point of this question. Why would anyone think it could be one of the other answers?

Hi Gaz,

The code I've posted is just some sample code to replicate the problem. When this happened in real life the persisted column was not just a repeat of another...

Oh ok, thanks for your responses.

Another day of sanity ahead.

Just found this

http://connect.microsoft.com/SQLServer/feedback/details/462042/incorrect-duplicate-key-error-with-unique-filtered-index

looks like it is a bug, although according to microsoft it was fixed in SP2 not SP1, so I don't know why you are not getting...

I am definitely going crazy then, I still get the error when I copy/paste your sql (all I added was the SELECT @@VERSION)

BEGIN TRAN

SELECT @@VERSION

CREATE TABLE UniqueTest (Col1 INT NOT...

I wasn't able to get an actual execution plan, as I could only get this behaviour when the statement is run as part of a stored procedure. I think the...

Nope, no errors, just never finishes executing.

Although, you are right I could safely add WITH (NOLOCK) on all of these joins.