It's already been tested. Against a measly million rows. It's a decryption function that is already CLR. It took far too long to be the least bit practical. We're talking most of a 24 hour day. It's supposed to take a long time to decrypt, so as to help ensure the security of the data. The solution for matching incoming data rows from the ETLs is to have the match take place against a separate HASH value that is static for a given input, as opposed to simply encrypting the incoming value and matching it against the existing encrypted value, because that last CANNOT work... The encryption algorithm will produce a different value based on when it runs, but the decryption routine still has to be able to decrypt everything that gets encrypted, regardless of when. When I tell you that source code is proprietary, it's proprietary for a fiscal reason. It's highly secure, and thus has high dollar value.

We don't own the source. Anyway, the only viable solution for matching in the long run is to use the hash function on the incoming value as part of the ETL, and stage that data for matching by the rules engine, which can easily match hash value to hash value nearly instaneously, and for all likely incoming volumes and well beyond.

What we were hoping for was an easy way to take that hashing function and just CLR it so that the ETL would no longer need to do that piece of work, but alas, the requirements for same can't be met in the environment this needs to go into. We don't need to improve hashing performance. We just need to stop having to decrypt a large number of rows just to be able to match incoming data. We already know that the decryption function is just as unavailable to us as the hashing function source (and for the same reason), so that's not a "replaceable" component either. We also know that there's no way to "change the process" to provide a means of further limiting that number of rows to a much smaller subset of the database. Sorry my friend, but it's time for you to grab a beer popsicle and we'll commiserate over the limits the dang "real world" keeps lobbing over our cubicle walls.