|
Вопрос к Павлу (по поводу Access и SQL Server)
|
|||
---|---|---|---|
#18+
Вы тут с Taurus'ом общались на тему Access'а и триггеров, но самое интересное осталось за кадром, в массы донеслось только "...в начале триггера обязательно ставь Set Nocount On" Обнародуй, пожалуйста! ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2000, 18:25 |
|
Вопрос к Павлу (по поводу Access и SQL Server)
|
|||
---|---|---|---|
#18+
С Set Nocount On все очень просто. Access как клиент - жуткий параноик. Если при изменении/добавлении/удалении записей через его интерфейс (таблица, форма, запрос) затрагивается больше записей, чем Access планировал, то выдается ошибка. Определяет он это через серверную функцию @@ROWCOUNT. А Set Nocount On просто вырубает счетчик @@ROWCOUNT'а. Да и с отключеным каунтом выполнение триггера/процедуры идет быстрее. Так что во всех случаях когда нет необходимости знать сколько записей участвовало в операции рекомендуется ставить Set Nocount On. Да и сам MSSQL в сложных процедурах без вырубленного каунта иногда 'шизеет'. А насчет остального - по ссылке все подробно описано. Если есть вопросы - с удовольствием отвечу. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2000, 05:50 |
|
Вопрос к Павлу (по поводу Access и SQL Server)
|
|||
---|---|---|---|
#18+
Спасибочки! С удовольствием спрошу, если приспичит. А по какой, кстати, ссылке все подробно описано? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2000, 10:54 |
|
Вопрос к Павлу (по поводу Access и SQL Server)
|
|||
---|---|---|---|
#18+
Уважаемый Павел! Не вводите в заблуждение массы!!! Set Nocount On НЕ "просто вырубает счетчик @@ROWCOUNT'а" @@ROWCOUNT остаётся всегда правильным. Set Nocount On - запрещает вывод рекордсета о @@ROWCOUNT'е в клиентское приложение. Set Nocount Off - может вызвать ошибки клиентского приложения и замедляет работу из-за вывода доп. рекордсетов ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2000, 12:35 |
|
Вопрос к Павлу (по поводу Access и SQL Server)
|
|||
---|---|---|---|
#18+
2 alexeyvg: Действительно, @@ROWCOUNT считает записи всегда. Ну и Вы людей в заблуждение не вводите! О каких таких рекордсетах идет речь? Насколько я понимаь, Recordset это обьект, генерируемый микрософтовскими библиотеками (Dao, Ado или ODBC Direct) на клиенте. Так при чем тут сервер? Можно тем же Аксессом получить результат процедуры вообще без всяких рекордсетов. А вот что происходит на самом деле (Books Online): "SET NOCOUNT (T-SQL) Stops the message indicating the number of rows affected by a Transact-SQL statement from being returned as part of the results." т.е. всего лишь отрубается часть результата запроса, которая несет в себе информацию о количестве записей (nn rows affected). ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2000, 06:52 |
|
Вопрос к Павлу (по поводу Access и SQL Server)
|
|||
---|---|---|---|
#18+
2 alexeyvg: Действительно, @@ROWCOUNT считает записи всегда. Ну и Вы людей в заблуждение не вводите! О каких таких рекордсетах идет речь? Насколько я понимаь, Recordset это обьект, генерируемый микрософтовскими библиотеками (Dao, Ado или ODBC Direct) на клиенте. Так при чем тут сервер? Можно тем же Аксессом получить результат процедуры вообще без всяких рекордсетов. А вот что происходит на самом деле (Books Online): "SET NOCOUNT (T-SQL) Stops the message indicating the number of rows affected by a Transact-SQL statement from being returned as part of the results." т.е. всего лишь отрубается часть результата запроса, которая несет в себе информацию о количестве записей (nn rows affected). 2 Staple: http://nsa.chat.ru/Secur_Gluk_04.html И совет. Если есть вопросы по Acctss а не по MsSql то посети http://c85.cemi.rssi.ru/Access/AnsPoint.htm Там получше меня ответят. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2000, 06:56 |
|
|
start [/forum/topic.php?fid=46&msg=32001337&tid=1827516]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
others: | 268ms |
total: | 402ms |
0 / 0 |