Кто практикует. Если база на SQL проще, через ADODB подключаться и проверять определенные данные. Чем это вообще опасно. Пока права пропадают.
Завел пользователя sql для конкретной базы и дал ему права на одну единственную табличку. Иногда права на эту табличку исчезают.
Почему?

(0) кто на ком стоял ?

(1) У тебя есть базы и общие объекты между ними. Объекты часто меняются в одной важной базе и в зависимости от их свойств после изменения в других база они должны вести себя по другому. Обмены и COM соединения не годятся так как требуется оперативность. Решил использовать прямые подключения. Слетели права.

а как связаны права пользователя с вашим решением? Как решили, так сразу и отвалились права от испуга?

(3) Они иногда пропадают. Пока не выяснил от чего. Может после обновления конфигурации.

(0) Может, при реструктуризации этой таблички. В этом случае 1С может её физически пересоздавать.
При частых обращениях можно просто удерживать COM-соединение 1С. Основные тормоза - на подключении.
Вообще, обычная выборка из стороннего подключения вроде ничем не чревата (если она быстрая).

(0) Поддержу идею в (5). Удерживать COM-соединение - ИМХО, самое верное решение.

(5) Ну да, обычный SELECT из таблицы документов. Работает очень быстро.

(6) Если лицензии программные то минус одна лицензия при этом.

(8) а грабли с табличкой - это лучше? а если при реструктуризации очередной поменяется название таблички, с doc2242 на doc2243?

(9) Вот. Это мне и важно знать. 1С меняет название табличек в каких случаях?

(8) Ну, тогда варианта два вижу. Или стучаться под dbo, или повесить в шедулере скрипт, восстанавливающий слетевшие права.
(9) Такого быть не может

(11) Мне на админ по sql также и сказал. Предложил job в sql создать каждый раз права переназначающий. Я решил пока выяснить почему они могут сбрасываться.

(11) если добавлены нетиповые объекты, при обновлении добавляются новые типовые - разве не происходит изменение индекса таблицы нетипового документа?

(13) Головой не поручусь, но - нет. Это было бы глупо. Думаю, что при включении возможности изменения конфы на поддержке, просто начинают использоваться соответствия между айдишниками метаданных рабочей конфы и конфы поставщика.
Где-то в толстой книжке даже вроде был описан способ, как можно при обновлении поставить новый типовой объект в соответствие уже существующему нетиповому. И упомянуто, что это необратимая операция.

(12) Дык а моё объяснение не канает? Перед слетами были реструктуризации этой таблички или нет?

(14) Просто на практике было, на копии до обновления, в профайлере взял запрос по нетиповому документу, в рабочей базе ругнулся на эту таблицу, посмотрел структуру - этому документу соответствует уже другая таблица.
У нас обновления редко проходят, поэтому проверить действительно-ли причина изменения индекса таблицы в этом также не могу.

(15) Был добавлен реквизит.

(16) Хм... Могло быть так, что копия была сделана ДО добавления в рабочую базу этого нетипового документа?

(17) Вполне могло быть. При реструктуризациях 1С кажись создает копию таблицы с суффиксом, делает там все что нужно, потом прибивает исходную и новую переименовывает. При добавлении реквизита это выглядит глуповато, но в целях унификации скорее всего тоже так делает.

(18) нет, это старый нетиповой документ.)

правильно веб сервис поднять

(20) Тогда, возможно, ты прав. Но это означает, что при каждом обновлении могут меняться идентификаторы и имена таблиц старых объектов. Фигня какая-то...

(22) угу. Жду следующего обновления чтобы проверить действительно-ли это так.