Fixed: RE7 post-migration "CLR strict security" + Blackbaud.AppFx.RE7.SqlClr assembly trust error (Native error 10314) – full SQL scripts

After a recent SQL Server migration (2017+), we started getting the classic CLR assembly trust error when opening constituent records in Raiser's Edge 7:

An error occurred in the Microsoft .NET Framework while trying to load assembly id XXXXX.

The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE.
(Native error: 10314)

The assemblies Blackbaud.AppFx.Fuzzy and Blackbaud.AppFx.RE7.SqlClr showed as SAFE_ACCESS but were being blocked by the new clr strict security setting.

Here’s the exact sequence that fixed it permanently:

Confirm the problem
-- Check CLR strict security
SELECT name, value, value_in_use
FROM sys.configurations
WHERE name = 'clr strict security';

-- Check assemblies
SELECT name, permission_set_desc, is_visible, create_date
FROM sys.assemblies
WHERE name LIKE '%blackbaud%' OR name LIKE '%re7%' OR name LIKE '%sqlclr%';You should see clr strict security = 1 and the two Blackbaud assemblies.

Get your own SHA2_512 hashes
SELECT
a.name,
CONVERT(VARCHAR(MAX), HASHBYTES('SHA2_512', CONVERT(VARBINARY(MAX), af.content)), 2) AS assembly_hash
FROM sys.assembly_files af
JOIN sys.assemblies a ON af.assembly_id = a.assembly_id
WHERE a.name IN ('Blackbaud.AppFx.Fuzzy', 'Blackbaud.AppFx.RE7.SqlClr')
AND af.file_id = 1;

Copy the two hash values that appear (one for each assembly).
Trust the assemblies (the fix)
-- Replace the hashes below with the two values from your query above
EXEC sp_add_trusted_assembly
@hash
= 0x[YOUR_FIRST_HASH_HERE],
@description
= N'Blackbaud.AppFx.Fuzzy';

EXEC sp_add_trusted_assembly
@hash
= 0x[YOUR_SECOND_HASH_HERE],
@description
= N'Blackbaud.AppFx.RE7.SqlClr';-- Verify
SELECT description, create_date FROM sys.trusted_assemblies;
Make sure REUser has the required server permission
USE master;
GRANT VIEW SERVER STATE TO REUser;

After running these, close and reopen The Raiser’s Edge completely. Constituent profiles should load without the CLR error.Why this fix matters

This wasn’t just a technical annoyance — it was blocking our security team from decommissioning old RE7 servers that had been a security risk and licensing cost for years. Once the profiles loaded reliably, they could finally move forward with decommissioning.

If your organization is also stuck in “we can’t turn off the old server yet” limbo (especially with the RE7 sunset coming in 2027), this sequence usually gets you unstuck in under 30 minutes.

This has now been rock-solid for us after the migration. Hope it saves someone else the multi-day headache (and the security team a lot of stress).

If you run the scripts and still hit a snag (different hash, different error, etc.), feel free to reply here with the exact output and I’ll help troubleshoot. I also occasionally take on remote RE7 migration rescue work if your team needs it done quickly.