SQL State: HYT00 Native: 0 Message: [Microsoft][ODBC SQL Server Driver]Время ожидания истекло Здравствуйте! 1С77, Win2003, SQL2000. На абсолютно безобидном участке кода 1С (внедрено и работает без изменений более года) начался сабж... Если Доки.НайтиПоНомеру(ТЗ.ИДДока)=0 Тогда : {Обработка.Обмен.Форма.Модуль(2863)**: SQL State: HYT00 Native: 0 Message: [Microsoft][ODBC SQL Server Driver]Время ожидания истекло Внешне вроде бы с данным сервером всё ОК, место есть, скульные регламенты на базе 1С (шринк, реиндекс и проч…) – регулярно выполняются… Куда копать? |
может хотя бы датами ограничить ? Переменная "Доки" какого типа ? |
1-Maximus23region > Датами - не желательно... Но ограничу, если не найду решения. Доки - типа СоздатьОбъект("Документ.ТакойТоВид"); |
Вообще-то, НайтиПоНомеру(Номер,Дата) и НайтиДокумент(ссылка) - весьма разные методы. Судя по написанному (ТЗ.ИДДока) бедный скуль вспотел шибко, ищя среди номеров строковое выражение, совпадающее со строковым выражением ссылки... |
датами по нумератору однозначно |
3-VZ > Валера, ну ты меня совсем за чайника держишь... :-) Бедный скуль не потеет, а прекрасно отрабатывает данную конструкцию (примерно 500 раз)... Загрузит документов 500 и зависает... Бедная юзерша - запускает загрузку заново... Уже загруженные доки - пролетают, грузится новая порция, потом опять зависон... Юзер опять жмакает загрузку... До прошлой пятницы - всё работало без зависонов. ТЗ.ИДДока - 100% число. Всегда. =ЧИСЛО(Payment.ПолучитьАтрибут("id")); |
5-DeiMos > [em]ТЗ.ИДДока - 100% число. Всегда.[/em] А поле DocNo - строка... Та зачем скуля лишний раз думать заставляешь? И вообще. 500 раз это выполнять. Тут внаглую запрос с параметрами просится. |
6-Sadovnikov > Немножко ты меня не понял. Это выполняется 1 раз, а не 500. При загрузке каждого документа. А таких документов - загружается больше тысячи в день. Одной обработкой, из xml файлов. По 1 файлу на каждый документ. |
7-DeiMos > Я вот из этого исходил: [em]Бедный скуль не потеет, а прекрасно отрабатывает данную конструкцию (примерно 500 раз)...[/em] Но цифра "больше тысячи в день" еще больше намекает на использование нормальных запросов. |
5-DeiMos > Вообще-то, я исхожу из того, что грамотный специалист присваивает идентификаторы не абы как, а со смыслом. Исходя из этого, я расшифровал идентификатор [em]ИДдока[/em] как ссылку. Или основную часть полной ссылки на документ, вроде поля IDDOC из таблицы 1SJORNAL. Это поле типа строка, размерностью 9, и там содержится нечто вроде "....1LX" (точки изображают пробелы). Бог с ним, что для поиска вовсе не обязательно транслировать это в десячичное число (мы же не собираемся производить с ним вычисления, так?). Главное, это вовсе не дублер поля DOCNO. Хотя это поле строковое, конвертировать его в число строго не рекомендуется. И что характерно, в методе НайтиДокумент поиск идет по полю IDDOC, а в методе НайтиПоНомеру - по полю DOCNO и полю DATE. В связи с чем выражение из (0) [em]Доки.НайтиПоНомеру(ТЗ.ИДДока)=0[/em] лично меня погружает в глубокую печаль. P.S. И отчего-то крутится в мозгу фраза "Вы бы, сударь, или крестик сняли, или трусы надели". |
+9 В сабже задача не раскрыта, потому есть два варианта оной: 1. Юзер тыкает пальчиком (мышой) в строку списка документа, и далее ищутся в базе места, где этот документ прописал свою ссылку. 2. Юзер либо мучительно вспоминает номер документа "после вчерашнего", или смотрит на бумажку, и хочет опять же найти места, где есть ссылка на этот документ. С целью посмотреть, что же он ввел, например. Или испортить его. Или еще что. Так вот, в первом случае надо непременно задействовать именно ссылку. Из которой легко и просто вырезать IDDOC для дальнейшего поиска. И даже не продвинутые, вполне типовые методы, справляются с этой задачей быстро, ибо IDDOC уникален, и неповторим. И метод НайтиДокумент как раз работает с этим полем. Во втором случае номера мало. Нужна дата. Точнее, период уникальности номера. Или несколько смежных. Даже если манагер срёт кирпичами, утверждая, что этот номер только в этом году использован. И использовать надо метод НайтиПоНомеру. Включив в параметры дату. И именно номер документа, а не его ссылку. Или кусок ссылки. |
9-VZ > "Вообще-то, я исхожу из того, что грамотный специалист присваивает идентификаторы не абы как, а со смыслом" ИДдока - это цифра. Создаваемая в другом ПО (не 1С). И она там именно так и называется в том ПО, именно как "ID". Таким образом, ЧИСЛО(Payment.ПолучитьАтрибут("id")); - с моей стороны излишне. Просто для подстраховки. Но на этом участке не тормозит. Ничего критичного, сервак не вспотеет число в число перевести. Нумерация доков в 1С - числовая, без периодичности. Т.е. "По всем данного вида". Т.е. - именно по DOCNO мне и нуно. Не ограничиваю по датам, потому что могут приходить документы тыщулетней давности. Такое редко, но бывает... (Суд повторный, или спустя годы сказался вред здоровью, или наследники объявились и т.п....). 10-VZ > Никаких манагеров (на такой объём работы - манагеров нужно роту сажать). Всё на полном автомате. Загружаются тыщи документов. Затем по нажатию кнопки создаётся столько же платёжек на различные суммы, затем по нажатию - все эти платёжки уходят в Выписку и далее в клиент-банк на оплату. "P.S. И отчего-то крутится в мозгу фраза "Вы бы, сударь, или крестик сняли, или трусы надели". " - Валера, не надо ехидничать и критиковать мой код и архитектуру решения. Поверь, я всё сделал ОЧЕНЬ грамотно. Мне нужно именно разобраться с поведением SQL-сервера. С "плавающим" фантомом из сабжа. Кстати, вчера никаких тормозов из сабжа не наблюдалось. Всё загрузилось "влёт", с первой попытки. Вот такой вот трудноотловимый зависон... В принципе, некритично. Пользователь не вспотеет нажать кнопку "загрузка" несколько раз после сбоев, догружая порциями... Однако, хотелось бы самому разобраться. |
11-DeiMos > [em]Нумерация доков в 1С - числовая[/em] А вот это уже никого не интересует - все равно в таблице строка. |
12-Sadovnikov > DOCNO - строка? Уверен на 100%? |
CREATE TABLE [dbo].[_1SJOURN]( [ROW_ID] [int] IDENTITY(1,1) NOT NULL, [IDJOURNAL] [int] NOT NULL, [IDDOC] [char](9) NOT NULL, [IDDOCDEF] [int] NOT NULL, [APPCODE] [smallint] NOT NULL, [DATE_TIME_IDDOC] [char](23) NOT NULL, [DNPREFIX] [char](18) NOT NULL, [DOCNO] [char](19) NOT NULL, |
14-Sadovnikov > Гхм.... А ведь верно, поиск доков даже определённого вида по номеру - всё равно производится в общем журнале... ОК, попробую убрать ЧИСЛО( |
6-Sadovnikov > Большое спасибо! Мысль интересная насчёт DocNo, буду копать в этом направлении. |
Текущее время: 08:10. Часовой пояс GMT +3. |