Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
привет!

сейчас имею
insert #tmpConflictArticles 
	exec sp_MShelpmergeconflictcounts 


              if not exists(select * from #tmpConflictArticles)
			begin
				drop table #tmpConflictArticles
				commit tran
				return
			end

ну раз незя INSERT EXEC в моем контексте, как мне можно просто узнать вернула ли хоть одну запись системная процедура sp_MShelpmergeconflictcounts, не залезая внутрь ее логики?

Заранее спасибо!
10 ноя 08, 08:54    [6415108]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
aleks2
Guest
exec sp_MShelpmergeconflictcounts 
if @@rowcount>0 begin
...
end

может пойдет?
10 ноя 08, 09:02    [6415135]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
aleks2
exec sp_MShelpmergeconflictcounts 
if @@rowcount>0 begin
...
end

может пойдет?


да, спасибо! а как предотвратить возвращение рекордсета из exec sp_MShelpmergeconflictcounts?

т.е. мне нужно узнать кол-во записей, а потом идти дальше в процедуре.

SET NOCOUNT ON
почему то возвращает((
10 ноя 08, 09:15    [6415167]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
set nocount on
выключает возврат информации типа "N rows were affected", а к возвращаемым рекордсетам не имеет никакого отношения.

В вашем случае я думаю, что единственный путь - взять кусок текста из системной хп.
10 ноя 08, 09:23    [6415199]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
GreenSunrise
set nocount on
выключает возврат информации типа "N rows were affected", а к возвращаемым рекордсетам не имеет никакого отношения.

В вашем случае я думаю, что единственный путь - взять кусок текста из системной хп.


Ооо, GreenSunrise я Вас ждал:) Вы кажется в репликации хорошо разбираетесь:)
Подскажите, вот я пишу самописную прогу решения конфликтов merge-replication с push полписками.
каков алгоритм проверки наличия конфликтных записей и что нужно делать в случае решения конфликтов вручную?
Сейчас у меня конфликты решаются арбитром сначала, а потом человек из бэкофиса видит список конфликтов и может менять победителя (Как conflict viewer). Пытался проследить логику из profiler, но так до конца и не смог((
10 ноя 08, 09:30    [6415230]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
А зачем самописную? Чем конкретно не устраивает интерактивный конфликт-резолвер? Он как раз и предназначен для разрешения конфликтов вручную человеком.
10 ноя 08, 09:34    [6415241]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
Еще один момент: у меня сейчас 3 базы подписчиков и база издателя. Так вот проблемы при тестинге у меня возникают при паралелльном update в базе данных издателя. Это нормально или же лучше вынести БД издателя в отдельную базу, а тот, кто центр, его сделать также подписчиком? (тут просто вопрос денег и поэтому "просто потому что так проще" не прокатит:) )
10 ноя 08, 09:37    [6415251]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
GreenSunrise
А зачем самописную? Чем конкретно не устраивает интерактивный конфликт-резолвер? Он как раз и предназначен для разрешения конфликтов вручную человеком.


безопасность + названия столбцов и таблиц понятным языком, т.к. это будет делать человек не разбирающийся в этом всем.
10 ноя 08, 09:38    [6415257]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
relief
GreenSunrise
А зачем самописную? Чем конкретно не устраивает интерактивный конфликт-резолвер? Он как раз и предназначен для разрешения конфликтов вручную человеком.


безопасность + названия столбцов и таблиц понятным языком, т.к. это будет делать человек не разбирающийся в этом всем.


а еще такой момент - из базы мало что удаляется, а просто статусы меняются. так в ConflictViewer юзер просто будет видеть цифры (статусы), которые ему ни о чем не будут говорить
10 ноя 08, 09:41    [6415266]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Какой-то поток сознания, честное слово...

relief
Так вот проблемы при тестинге у меня возникают при паралелльном update в базе данных издателя.

Какие проблемы? Сиквел так и пишет - "у меня проблема"?

relief
Это нормально или же лучше вынести БД издателя в отдельную базу, а тот, кто центр, его сделать также подписчиком? (тут просто вопрос денег и поэтому "просто потому что так проще" не прокатит:) )

Че? Что такое "вынести базу в отдельную базу"? Поток сознания мутнел на глазах.

relief
а еще такой момент - из базы мало что удаляется, а просто статусы меняются. так в ConflictViewer юзер просто будет видеть цифры (статусы), которые ему ни о чем не будут говорить

Какие статусы? Че за хрень вообще? Вы бы сами хоть прочитали свой топик, а?
10 ноя 08, 20:44    [6419713]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
[quot GreenSunrise]skeppedquot]

Смотрите,

есть центральный сервер (MsSqlServer) и 2 подписчика (SqlExpress) - мердж репилакция.
Сейчас данные могут менять все 3 сервера параллельно, но данные ввиду SqlExpress проходят через MsSqlServer. Он и выстпает издателем\дистрибьютером.

1. резолвер пишу, чтобы названия таблиц\столбцов выводить на русском языке.
2. Во многих таблицах используются внешние ключи типа "статус клиента" и нужно выводить это пользователю не ввиду статус = 1, а статус - архивный
3. в текующей архитектуре возникает проблема следующего типа: если параллельно изменят записи сервер и подписчики, то при выборе в качестве победителя подписичка1 теряются данные сервера, которые нужны при решении конфликта с подписчиком2, т.к. судя по профайлеру данные тупо апдейтятся из конфликтной таблицы проигравшей записи в серверную таблицу. конечно здесь можно что-то придумать, но мне кажется проще сделать сервер тоже подписчиком на express, а издателем сделать базу с которой никто не будет работать.
11 ноя 08, 09:32    [6420623]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
relief
1. резолвер пишу, чтобы названия таблиц\столбцов выводить на русском языке.

Таблицы и столбцы в них можно называть по-русски.

relief
2. Во многих таблицах используются внешние ключи типа "статус клиента" и нужно выводить это пользователю не ввиду статус = 1, а статус - архивный

Тут еще надо подумать... Есть, конечно, вариант с вычисляемыми полями, но он может быть не очень удобным...

relief
3. в текующей архитектуре возникает проблема следующего типа: если параллельно изменят записи сервер и подписчики, то при выборе в качестве победителя подписичка1 теряются данные сервера, которые нужны при решении конфликта с подписчиком2, т.к. судя по профайлеру данные тупо апдейтятся из конфликтной таблицы проигравшей записи в серверную таблицу. конечно здесь можно что-то придумать, но мне кажется проще сделать сервер тоже подписчиком на express, а издателем сделать базу с которой никто не будет работать.

Это у вас тупо стоит дефолтный конфликт резолвер, в котором всегда побеждает паблишер. Поставьте другой, какой вас устраивает - последний побеждает, первый побеждает или выберите из еще десятка стандартных резолверов.
11 ноя 08, 13:30    [6422615]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Вы могли бы сказать принцип, по которому у вас некто Вася выбирает победителя в конфликте? Не за красивые же глаза он говорит, что вот эта запись победила.
11 ноя 08, 13:32    [6422630]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
GreenSunrise
Вы могли бы сказать принцип, по которому у вас некто Вася выбирает победителя в конфликте? Не за красивые же глаза он говорит, что вот эта запись победила.


в том то и то дело логика нечеткая, как в суде - судья решает все опираясь на факты
11 ноя 08, 15:50    [6423917]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Далана ;-) Так не бывает. Ну приведите хоть 3-4 примера, какие были факты и кто победил и почему. Я вот не верю вообще в необходимость вмешательства человека в разрешение конфликтов! Если нужен человек - значит, плохо система спроектирована, не формализована в достаточной степени.

Человек - он ведь по критериям выбирает, не от балды же. Выделите эти критерии и на основании их задайте резолвер.
11 ноя 08, 16:45    [6424386]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
GreenSunrise
Далана ;-) Так не бывает. Ну приведите хоть 3-4 примера, какие были факты и кто победил и почему. Я вот не верю вообще в необходимость вмешательства человека в разрешение конфликтов! Если нужен человек - значит, плохо система спроектирована, не формализована в достаточной степени.


ну к примеру.
Есть 3 оператора. Один что-то поменял, другой и третий в одном поле. У всех операторов одинаковые приоритеты и клиентские подписки. Побеждает кто первый изменил, НО третьему позвонил Генеральный директор и сказал поменять значение. Отсюда получаем нечеткую логику
11 ноя 08, 22:50    [6426113]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
Glory
Member

Откуда:
Сообщений: 104760
relief
GreenSunrise
Далана ;-) Так не бывает. Ну приведите хоть 3-4 примера, какие были факты и кто победил и почему. Я вот не верю вообще в необходимость вмешательства человека в разрешение конфликтов! Если нужен человек - значит, плохо система спроектирована, не формализована в достаточной степени.


ну к примеру.
Есть 3 оператора. Один что-то поменял, другой и третий в одном поле. У всех операторов одинаковые приоритеты и клиентские подписки. Побеждает кто первый изменил, НО третьему позвонил Генеральный директор и сказал поменять значение. Отсюда получаем нечеткую логику

А почему не назначить тогда одного специального оператора с высоким приоритетом ?
Автоматизация бардака приводит к автоматизированному бардаку
12 ноя 08, 10:28    [6427149]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
Glory
relief
GreenSunrise
Далана ;-) Так не бывает. Ну приведите хоть 3-4 примера, какие были факты и кто победил и почему. Я вот не верю вообще в необходимость вмешательства человека в разрешение конфликтов! Если нужен человек - значит, плохо система спроектирована, не формализована в достаточной степени.


ну к примеру.
Есть 3 оператора. Один что-то поменял, другой и третий в одном поле. У всех операторов одинаковые приоритеты и клиентские подписки. Побеждает кто первый изменил, НО третьему позвонил Генеральный директор и сказал поменять значение. Отсюда получаем нечеткую логику

А почему не назначить тогда одного специального оператора с высоким приоритетом ?
Автоматизация бардака приводит к автоматизированному бардаку


так и будет. только этому оператору нужно выводить всё в понятном виде и на русском языке. поэтому и пишу резолвер свой
12 ноя 08, 10:44    [6427267]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
Glory
Member

Откуда:
Сообщений: 104760
relief
Glory
relief
GreenSunrise
Далана ;-) Так не бывает. Ну приведите хоть 3-4 примера, какие были факты и кто победил и почему. Я вот не верю вообще в необходимость вмешательства человека в разрешение конфликтов! Если нужен человек - значит, плохо система спроектирована, не формализована в достаточной степени.


ну к примеру.
Есть 3 оператора. Один что-то поменял, другой и третий в одном поле. У всех операторов одинаковые приоритеты и клиентские подписки. Побеждает кто первый изменил, НО третьему позвонил Генеральный директор и сказал поменять значение. Отсюда получаем нечеткую логику

А почему не назначить тогда одного специального оператора с высоким приоритетом ?
Автоматизация бардака приводит к автоматизированному бардаку


так и будет. только этому оператору нужно выводить всё в понятном виде и на русском языке. поэтому и пишу резолвер свой

Вы прочто ? Должен быть оператор, изменения данных которым считаются приоритетными. И в стандартном ресолвере у него будет приоритет над другими операторами. И генеральный должен звонить не любому попавшемуся оператору, а этому единственному супер-оператору
12 ноя 08, 10:50    [6427310]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
Glory
Вы прочто ? Должен быть оператор, изменения данных которым считаются приоритетными. И в стандартном ресолвере у него будет приоритет над другими операторами. И генеральный должен звонить не любому попавшемуся оператору, а этому единственному супер-оператору


основная задача: выводить всё на доступном оператору языке. а в conflictResolver это нельзя увы.
12 ноя 08, 12:43    [6428261]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
Glory
Member

Откуда:
Сообщений: 104760
relief
Glory
Вы прочто ? Должен быть оператор, изменения данных которым считаются приоритетными. И в стандартном ресолвере у него будет приоритет над другими операторами. И генеральный должен звонить не любому попавшемуся оператору, а этому единственному супер-оператору


основная задача: выводить всё на доступном оператору языке. а в conflictResolver это нельзя увы.

В огороде бузина, а в Киеве дядька
12 ноя 08, 12:52    [6428346]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Glory абсолютно прав. Автоматизация бардака не решит проблему. Это в точности тот случай, когда проблема решается не программированием, а администрированием.

Совершенно правильное решение вам предлагают - завести отдельного оператора, который имеет наивысший приоритет. Все ваши ухищрения с резолвером в приведенном вами примере - бред.
12 ноя 08, 13:28    [6428655]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
relief
Member

Откуда:
Сообщений: 1197
GreenSunrise
Glory абсолютно прав. Автоматизация бардака не решит проблему. Это в точности тот случай, когда проблема решается не программированием, а администрированием.

Совершенно правильное решение вам предлагают - завести отдельного оператора, который имеет наивысший приоритет. Все ваши ухищрения с резолвером в приведенном вами примере - бред.


вы говорите про оператора который будет через conflictResolver решать всё?
12 ноя 08, 13:50    [6428829]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
Glory
Member

Откуда:
Сообщений: 104760
relief
GreenSunrise
Glory абсолютно прав. Автоматизация бардака не решит проблему. Это в точности тот случай, когда проблема решается не программированием, а администрированием.

Совершенно правильное решение вам предлагают - завести отдельного оператора, который имеет наивысший приоритет. Все ваши ухищрения с резолвером в приведенном вами примере - бред.


вы говорите про оператора который будет через conflictResolver решать всё?

Мы говорим про человека(логин), чьи действия в базе имеют больший приоритет, чем действия других людей(логинов).
12 ноя 08, 13:54    [6428853]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Должен быть отдельный репликационный партнер (паблишер или один из подписчиков), имеющий наибольший приоритет. Из СТАНДАРТНЫХ конфликт-резолверов вы выбираете priority-based резолвер. Доступ к ЭТОМУ ПАРТНЕРУ имеют только люди с наивысшими привилегиями. Весь арбитраж делается только с него.

Соответственно, изменения, сделанные на этом арбитражном сервере, всегда побеждают.

Можно не по приоритетам. Можно сделать таким арбитражным сервером паблишера. То есть рядовые изменения с него особо не вносятся, операторы на нем не сидят. Конфликт-резолвер выбираем ИЗ СТАНДАРТНЫХ "паблишер всегда побеждает".

И опять же получается, что изменения, сделанные на этом арбитражном сервере, всегда побеждают.
12 ноя 08, 14:05    [6428943]     Ответить | Цитировать Сообщить модератору
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Можно сделать с весами не серверов, а логинов. Добавить в таблицы поле - "вес" или приоритет логина. Целочисленное поле. При изменениях-добавлениях данных устанавливать это поле, исходя из логина текущего пользователя.

Тогда и выделенный арбитражный сервер не понадобится. Кем залогинишься, такие привилегии и имеешь. Если ты гендиректор, то твои изменения всегда побеждают.
12 ноя 08, 14:15    [6429027]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: An INSERT EXEC statement cannot be nested для системной процедуры  [new]
MikeCrazy
Guest
-- ФОРМАТ ПРОЦЕДУРЫ НА ЗАМЕНУ ТАБЛИЧНОЙ ФУНКЦИИ
CREATE PROCEDURE [SP_NAME](<CommonArgList>, @TmpTableId INT = 0)
AS BEGIN

CREATE TABLE #result_table (<SP_NAME_RESULT_FIELDS>)

IF isnull(@TmpTableId,0) = 0 BEGIN
SELECT DISTINCT * FROM #result_table
END ELSE BEGIN
declare @sql as varchar(max)
IF not exists(SELECT [name] FROM tempdb..sysobjects WHERE id=@TmpTableId ) BEGIN
set @sql = 'select ''error'' '
SELECT
@sql = 'select DISTINCT * into ' + name +
' from #result_table'
FROM tempdb..sysobjects WHERE id=@TmpTableId

exec (@sql)
END ELSE BEGIN
set @sql = 'select ''error'' '
SELECT
@sql = 'insert into ' + name +
' select DISTINCT *
from #result_table'
FROM tempdb..sysobjects WHERE id=@TmpTableId
exec (@sql)
END
END

END

--ИСПОЛЬЗОВАНИЕ ХРАНИМОЙ ПРОЦЕДУРЫ ДАННОГО ФОРМАТА (РЕЗУЛЬТАТ ВО ВРЕМЕННУЮ ТАБЛИЦУ СОЗДАННУЮ ЗАРАНЕЕ)
<...>

declare @<SP_NAME_ResultTable> INT
CREATE TABLE #<SP_NAME_ResultTable> (SP_NAME_RESULT_FIELDS) -- вобщемто любое имя, это не важно
SET @<SP_NAME_ResultTable> = OBJECT_ID('tempdb..#<SP_NAME_ResultTable>')
EXEC <SP_NAME> <CommonArgList>, @<SP_NAME_ResultTable>

<...>

--ЕСЛИ НЕ ПЕРЕДАВАТЬ ПОСЛЕДНИЙ ПАРАМЕТР - ПРОСТО ВЫВЕДЕТСЯ НА ЭКРАН
6 дек 12, 07:37    [13585332]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Microsoft SQL Server Ответить