Сушняк,
рисуй архитектуру с потоками данных и выкладывай здесь чтобы на пальцах
не объяснять (потому что пока что вариантов возможных решений - дюжины)

Есть push и pull
первый - данные запихивает MSSQL (инициатор)
второй - данные читает MySQL (инициатор)
судя по всему скорее всего вариант первый
т.к. из твоего описания это делается триггерами на его стороне
вот от сюда уже и надо копать по цепи - что делают триггеры
(и связанные процедуры/функции и пр.) там в коде
шаг за шагом и будет видно где кроется потерянное звено

TaPaKвеселее если орлы зашили это в clr и без исходников :)
умная третья сторона обычно как минимум так и делает если конечно
нет отдельного соглашения об открытости и прозрачности на проект
(т.е. интеллектуальная собственность - пользователя)
за отдельную плату/премию (закладывая в цену сделки).

хотя и это читается/перехватывается через dump памяти,
как-бы там библиотеки не шифровали - другое дело это
обычно нарушение (лицензионного) соглашения.

Relic Hunterа clr, что может само подключиться к чему угодно?
если снаружи - то к чему ему админ сети или сервера (FireWall) разрешит
если внутри - то как политики настроены:
т.е. под какой учёткой стартует и какие права у этой учётки

TaPaKvikkiv,
..
дивный новый мир, особенно "умная" веселит
если коротко: то любое решение на CLR всегда г..но
есть решения которые без этого по сложности/производительности функционально не реализуемы,
т.е. без CLR просто не существует, т.е. как-бы такие решения не называть (г.но или нет)
то не знаю как назвать ситуацию когда решения нет - а оно критически нужно бизнесу.

TaPaKпростой ответ: это не задача ms sql.
согласен и понимаю какой широкий круг задач имеется ввиду,
но пованговав - есть более узкая сфера где латентность обмена данными между
приложением и DB (фактически - исключение этого шага / слоёв) критична,
в смысле не надо уж так всё в одну корзину
архитектурно: есть место и для такого как критерий оптимальности
(т.е. относительно - всё остальное вполне получает статус г.)

ты просто скорее всего смотришь больше со стороны DB/DBA (inside box), а не
решения целиком в результате приоритет на локальный оптимум, а не глобальный.