html-помощники считывают значение из ModelState. И нет элегантного способа переопределить это поведение.
Но если вы добавите эту строку после SaveToDB(ID, SomeText)
, она должна работать:
ModelState["SomeText"].Value =
new ValueProviderResult("", "", CultureInfo.CurrentCulture);
использовать курсор
ДОБАВЛЕНИЕ: [пример курсора MS SQL]
declare @field1 int
declare @field2 int
declare cur CURSOR LOCAL for
select field1, field2 from sometable where someotherfield is null
open cur
fetch next from cur into @field1, @field2
while @@FETCH_STATUS = 0 BEGIN
--execute your sproc on each row
exec uspYourSproc @field1, @field2
fetch next from cur into @field1, @field2
END
close cur
deallocate cur
в MS SQL, вот пример статьи
обратите внимание, что курсоры медленнее, чем на основе набора операции, но быстрее, чем ручные циклы while; подробнее в этом вопросе SO
ДОБАВЛЕНИЕ 2: если вы будете обрабатывать больше, чем несколько записей, сначала поместите их во временную таблицу и наведите курсор на временную таблицу; это предотвратит перерастание SQL в блокировки таблиц и ускорит операцию
ДОБАВЛЕНИЕ 3: и, конечно, если вы можете встроить все, что ваша хранимая процедура делает для каждого идентификатора пользователя, и запустить все это как один оператор обновления SQL, это было бы оптимально
попробуйте изменить метод, если вам нужно выполнить цикл!
внутри родительской хранимой процедуры создайте таблицу #temp, содержащую данные, которые вам нужно обработать. Вызовите дочернюю хранимую процедуру, таблица #temp станет видимой, и вы сможете ее обработать, надеюсь, работая со всем набором данных без курсора или цикла.
это действительно зависит от того, что делает эта дочерняя хранимая процедура. Если вы выполняете UPDATE-ing, вы можете «обновить», присоединившись к таблице #temp, и выполнить всю работу в одном операторе без цикла. То же самое можно сделать для INSERT и DELETE. Если вам нужно выполнить несколько обновлений с IF, вы можете преобразовать их в несколько UPDATE FROM
с помощью таблицы #temp и использовать операторы CASE или условия WHERE.
При работе с базой данных постарайтесь забыть о мышлении зацикливание это реальная потеря производительности, вызовет блокировку / блокировку и замедлит обработку. Если вы повсюду зацикливаете, ваша система не будет очень хорошо масштабироваться, и ее будет очень трудно ускорить, когда пользователи начнут жаловаться на медленное обновление.
Опубликуйте содержимое этой процедуры, которую вы хотите вызвать в цикле, и я готов поспорить В 9 случаях из 10 вы могли бы написать его для работы с набором строк.
Что-то вроде этой замены потребуется для ваших таблиц и имен полей.
Declare @TableUsers Table (User_ID, MyRowCount Int Identity(1,1)
Declare @i Int, @MaxI Int, @UserID nVarchar(50)
Insert into @TableUser
Select User_ID
From Users
Where (My Criteria)
Select @MaxI = @@RowCount, @i = 1
While @i <= @MaxI
Begin
Select @UserID = UserID from @TableUsers Where MyRowCount = @i
Exec prMyStoredProc @UserID
Select
@i = @i + 1, @UserID = null
End
Разве это нельзя сделать с помощью определяемой пользователем функции для репликации того, что делает ваша хранимая процедура?
SELECT udfMyFunction(user_id), someOtherField, etc FROM MyTable WHERE WhateverCondition
где udfMyFunction - это созданная вами функция, которая принимает в идентификаторе пользователя и делает с ним все, что вам нужно.
См. http://www.sqlteam.com/article/user-defined-functions для получения дополнительной информации
Я согласен с тем, что курсоров действительно следует избегать там, где это возможно. И обычно это возможно!
(конечно, мой ответ предполагает, что вы заинтересованы только в получении вывода от SP и что вы не изменяете фактические данные. Я считаю, что «изменяет пользовательские данные определенным образом», немного двусмысленно по сравнению с исходный вопрос, поэтому подумал, что предлагаю это как возможное решение. Полностью зависит от того, что вы делаете!)