Нашому додатку потрібно однаково добре працювати з базою даних Oracle або базою даних Microsoft SQL Server. Щоб полегшити це, ми створили кілька UDF для гомогенізації нашого синтаксису запитів. Наприклад, SQL Server має GETDATE (), а Oracle - SYSDATE. Вони виконують ту саму функцію, але це різні слова. Ми написали обгортку UDF під назвою NOW () для обох платформ, яка поєднує відповідний синтаксис певної платформи у загальну назву функції. У нас є й інші такі функції, деякі з яких по суті нічого не роблять, але існують виключно заради гомогенізації. На жаль, це має вартість для SQL Server. Вбудовані скалярні АДС викликають погіршення продуктивності та повністю відключають паралелізм. В якості альтернативи ми написали функції складання CLR для досягнення тих же цілей. Коли ми розгорнули це до клієнта, вони почали часто зустрічатися з тупиками. Цей конкретний клієнт використовує методи реплікації та високої доступності, і мені цікаво, чи відбувається тут якась взаємодія. Я просто не розумію, як введення функції CLR може викликати подібні проблеми. Для довідки я включив оригінальне скалярне визначення UDF, а також визначення заміну CLR в C # і SQL-декларацію для нього. У мене також є XML з тупиком, який я можу надати, якщо це допоможе.
Оригінал UDF
CREATE FUNCTION [fn].[APAD]
(
@Value VARCHAR(4000)
, @tablename VARCHAR(4000) = NULL
, @columnname VARCHAR(4000) = NULL
)
RETURNS VARCHAR(4000)
WITH SCHEMABINDING
AS
BEGIN
RETURN LTRIM(RTRIM(@Value))
END
GOФункція складання CLR
[SqlFunction(IsDeterministic = true)]
public static string APAD(string value, string tableName, string columnName)
{
return value?.Trim();
}Декларація SQL Server для функції CLR
CREATE FUNCTION [fn].[APAD]
(
@Value NVARCHAR(4000),
@TableName NVARCHAR(4000),
@ColumnName NVARCHAR(4000)
) RETURNS NVARCHAR(4000)
AS
EXTERNAL NAME ASI.fn.APAD
GO