Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Глюк?
|
|||
|---|---|---|---|
|
#18+
Столкнулся я с одним глюком, причем уже не один раз. В Stored Procedure иногда после SQL команды либо больше ничего не работает, либо, например, не срабатывает команда RAISERROR. Вот пример: CREATE PROCEDURE ListRoomUpdate @UID int, @Caption varchar(50), @RoomSquare float, @UIDLocate int, @UIDTypeRoom int, @UIDParent int, @Taxrate money, @CountPlace float, @UIDQuality int, @DTActual datetime AS DECLARE @UIDRoomVar int BEGIN TRANSACTION TRA IF NOT EXISTS (SELECT UID FROM list_room WHERE ((Caption = @Caption) and (UID<>@UID))) BEGIN UPDATE list_room SET Caption=@Caption, DTUpdate=GetDate(), UIDParent=@UIDParent, RoomSquare=@RoomSquare, UIDLocate=@UIDLocate, UIDTypeRoom=@UIDTypeRoom WHERE UID = @UID END ELSE BEGIN ROLLBACK TRANSACTION TRA RAISERROR ('Помещение не найдено',16,1) RETURN END EXEC JournalRoomVarInsert @Taxrate, @CountPlace, @UIDQuality, @DTActual, @UID, @UIDRoomVar OUT IF (@UIDRoomVar IS NULL) BEGIN ROLLBACK TRANSACTION TRA END ELSE BEGIN COMMIT TRANSACTION TRA END GO Если перед командой UPDATE поставить RAISERROR (в этих же BEGIN END), он сработает, если после, не сработает. Перед EXEC JournalRoomVarInsert не сработает, хотя данная команда отрабатывается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2001, 09:55 |
|
||
|
Глюк?
|
|||
|---|---|---|---|
|
#18+
А чего это я не вижу здесь "SET NOCOUNT ON" в начале процедуры? Может очки новые выписать или ... этого просто нет? Тогда ты, братец, не прав. Немедля поставь! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2001, 11:13 |
|
||
|
Глюк?
|
|||
|---|---|---|---|
|
#18+
Что это такое? Можно чуть подробней, для чего это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2001, 12:18 |
|
||
|
Глюк?
|
|||
|---|---|---|---|
|
#18+
Посмотри в Books on line (т.е в хелпе на SQL-Server). Там лучше написано, чем я смогу объяснить. Короче говоря, так надо )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2001, 13:29 |
|
||
|
Глюк?
|
|||
|---|---|---|---|
|
#18+
Вообще я только разбираюсь с MSSQL, и пока гляжу на него квадратными глазами. Кроме того, более гнустного хелпа я еще не видел. Вообщем буду признателен за любое объяснение , хоть на пальцах, что это такое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2001, 13:42 |
|
||
|
Глюк?
|
|||
|---|---|---|---|
|
#18+
В результате выполнения процедуры могут возникнуть несколько так называемых result set-ов, т.е. результатов работы конкретных команд(SELECT, UPDATE, EXEC, ...). Например, количество записей обработанных в результате UPDATE - это отдельный result set В связи с эти в клиентском приложении может возникнуть некоторая путаница(назовем так) насчет того, какой result set считать окончательным результатом работы процедуры. Для этого и существует команда SET NOCOUNT { ON | OFF }, которая разрешает/запрещает генерировать к каждой команде счетчик обработанных данной командой записей. О самой команде см. BOL - Transact SQL reference - SET Немного о поднаготной см. BOL - Building Server pplications - ODBC and SQL Server - Processing Results. PS А BOL все-таки хорошая вещь - просто на первый взгляд(но только на первый) кажется, что топики там размещены "неправильно", но когда внимательно прочитаешь содержимое(а также посмотришь как этот топик расположен в дереве), то понимаешь, что скорее всего ты смотрел на проблему с неправильной стороны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2001, 14:26 |
|
||
|
Глюк?
|
|||
|---|---|---|---|
|
#18+
Вообщем проблема в том, что после выполнения UPDATE процедура вообще прекращает работать. Хотел бы я знать причину этого, а еще лучше, как от этого избавиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2001, 06:37 |
|
||
|
Глюк?
|
|||
|---|---|---|---|
|
#18+
Насколько я понял логику Вашей процедуры, Вы изменяете запись в таблице list_room используя условие WHERE UID = @UID, но перед этим проверяете, есть ли такая запись. В таком случае проверка должна быть не IF NOT EXISTS (SELECT UID FROM list_room WHERE ((Caption = @Caption) and (UID<>@UID))), а IF EXISTS (SELECT UID FROM list_room WHERE ((Caption <> @Caption) and (UID = @UID))) Или я что-то не понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2001, 07:14 |
|
||
|
Глюк?
|
|||
|---|---|---|---|
|
#18+
Знаешь очень сложно разобраться не зная логики того, что ты хочешь сделать. Может быть ты просто запутался. Если нет, то смоделируй эту ситуацию на более простом примере. Тогда я уверен что тебе смогут обяснить, что ты неправильно делаешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2001, 07:31 |
|
||
|
Глюк?
|
|||
|---|---|---|---|
|
#18+
>Владимир Смирнов Нет, у меня вроде правильно, я получаю уникальный идентификатор ячейки и новый caption для него, и проверяю, а нет ли уже другой записи с этим caption , при условии, что эта запись уже может иметь такой caption (т.е. меняем его на такой же как и был). Собственно говоря все оказалось просто и я в определенных ситуациях не устанавливал значение переменной @UIDRoomVar , что приводило к откату транзакции. Хотя ошибка с несрабатыванием RAISERROR всеж присутствовала, может глюк, а может и руки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2001, 07:51 |
|
||
|
|

start [/forum/topic.php?desktop=1&fid=46&tid=1825268]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
36ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 252ms |
| total: | 368ms |

| 0 / 0 |
