2009-10-02 4 views
0

У нас есть приложение C#, которое отправляет в базу данных, которая реплицируется в другую базу данных (с использованием репликации слиянием) и имеет один настраиваемый распознаватель, который является хранимой процедурой.Репликация Пользовательский преобразователь изменяет пустые строки на NULL

Это нормально работало под SQL Server 2000, но при тестировании в SQL Server 2005 пользовательский резольвер пытается изменить любые пустые столбцы varchar на нуль (и с ошибкой, поскольку этот конкретный столбец не разрешает значения null).

Обратите внимание, что эти поля varchar не являются теми, которые вызывают конфликт, поскольку они являются текущими пустыми в обеих базах данных и не изменяются, и хранимая процедура не изменяет их (все, что он делает, пытается установить значение другая колонка денег).

Кто-нибудь сталкивался с этой проблемой или имел пример хранимой процедуры, которая оставит пустые строки такими, какие они есть?

Фактическая хранимая процедура достаточно проста и перерасчет баланса клиента в случае возникновения конфликта.

ALTER procedure [dbo].[ReCalculateCustomerBalance] 
    @tableowner sysname, 
    @tablename sysname, 
    @rowguid varchar(36), 
    @subscriber sysname, 
    @subscriber_db sysname, 
    @log_conflict INT OUTPUT, 
    @conflict_message nvarchar(512) OUTPUT 
AS 
    set nocount on 
DECLARE 
    @CustomerID bigint, 
    @SysBalance money, 
    @CurBalance money, 
    @SQL_TEXT nvarchar(2000) 

    Select @CustomerID = customer.id from customer where rowguid= @rowguid 

    Select @SysBalance = Sum(SystemTotal), @CurBalance = Sum(CurrencyTotal) From CustomerTransaction Where CustomerTransaction.CustomerID = @CustomerID 

    Update Customer Set SystemBalance = IsNull(@SysBalance, 0), CurrencyBalance = IsNull(@CurBalance, 0) Where id = @CustomerID 

    Select * From Customer Where rowguid= @rowguid 

    Select @log_conflict =0 
    Select @conflict_message ='successful' 
    Return(0) 
+0

Можете ли вы опубликовать проблему в своей хранимой процедуре? Это не звучит знакомо, хотя, возможно, была проблема с 2000 или 2005 годом, которая была бы подсвечена, если бы мы увидели вашу сохраненную proc. – Erich

+0

Я включил всю хранимую процедуру, поскольку она довольно короткая. Тем не менее, та же ошибка возникает, если я удаляю первые два выбора и заменяю обновление на что-то вроде: - Update Customer Set SystemBalance = 0, где rowguid = @rowguid – sgmoore

+0

Что именно происходит с ошибкой? Это ошибка SQL, или на C# где-то? Какие поля/поля являются «проблемными»? Я не вижу случая, когда это могло бы возвращать nulls через что-либо, кроме как через оператор Select *. Единственный способ, которым я могу понять, что это происходит, - это если запись не существует. Не могли бы вы попытаться назвать столбцы в выборе или сделать, где будет где id = @ customerId? – Erich

ответ

0

У вас есть несколько вариантов здесь, каждый немного обходной путь от того, что мои исследования, кажется, показывают, проблема с SQL Server.

1 Alter это утверждение: Select * From Customer Where rowguid= @rowguid явно упомянуть каждого из столбцов, и использовать «IsNull» для обижая полей

2- Alter столбец в таблице, чтобы добавить ограничение по умолчанию для «». Это будет сделано, если вы попытаетесь вставить «нуль», он заменит его пустой строкой

3- Добавить триггер «перед вставкой», который будет изменять данные перед вставкой, чтобы не содержать 'null' больше

PS: Вы уверены, что система репликации имеет этот столбец, обозначенный как «обязательный»? Я думаю, что если это не требуется, он будет вставлять «null», если данных не существует.

+0

Спасибо за предложения. Мне может потребоваться некоторое время, чтобы проработать их все. Я попробовал вариант 2, где я фактически установил ограничение по умолчанию на букву a (чтобы было легче увидеть, когда он был применен). В этом случае пустая строка по-прежнему была заменена на нуль. Я не уверен, что понимаю, что вы подразумеваете под требуемой колонкой. Он определенно включен в репликацию. Если это не то, что вы имели в виду, как я могу проверить статус «обязательно»? – sgmoore

+0

Я не уверен, я заметил это во время поиска SQL-репликации. По-видимому, есть какие-то настройки, где вы можете сказать, требуется ли это или нет. – Erich

+0

Предложение 1 не имело никакого значения. На этапе выполнения хранимой процедуры нигде нет нигде. Нет 3 кажется более перспективным. Хотя это Microsoft Sql, есть (насколько мне известно) нет такой вещи, как «перед вставкой». Мне придется больше читать «вместо триггеров» (которые я раньше не использовал). Однако временное разрешение пустых значений и добавление триггера после обновления позволяет мне возвращать пустые строки. Независимо от того, работает ли это, зависит ли какой-либо столбец, который допускает null, а обрабатывает их как нечто отличное от пустой строки. – sgmoore