CODEBASE error "unrecognized field name" на SQL базе. Откуда? #547640

Непонятно с чего и в какой момент SQL база при работе стала выдавать CODEBASE ERROR #210 "unrecognized field name". Притом названия полей меняются в одной и той же ситуации. Видел различные SPxxxx, IDDOC, PERIOD. Ошибка выдаётся нерегулярно. Вылезла, например, при открытии документа, тут же документ закрыл/открыл - ошибки нет. Или есть, но ругается на другое поле. Может кто знает, что это за фигня? Windows Server 2003, MSSQL 2005, терминал, 1С 7.70.027. Есть смутное подозрение, что как-то виноваты обновления сервера, которые админ накатывал на этих выходных. Но какие и каким образом?

1c использует свой словарь DD для сопоставления имен метаданных и физ таблиц, варианты (в порядке убывания вероятности): 1. кто-то балуется со словарем 2. используешь нештатный доступ к базе, внешние ВК и т.д. 3. SQL права ограничивают доступ к отдельным полям 4. средсва защиты конфигурации

Словарь-то словарь, но база-то SQL. И запускается нормально. То есть, формально, на сколько 1С может проверить, база данных соответствует DDS. К тому же я не могу представить, что такое должно случиться в DDS, что бы 1С-ка ругалась на поле PERIOD. Ошибка, как я понимаю, возникает, когда 1С кладет результат запроса к SQL-серверу во временный DBF-ник и вот тут что-то и происходит. 1. Со словарйм ни кто не балуется. 2. ВК есть FormEx, 1C++, Йоксель и SvcSvc. Версии не обновлялись уже давно. Нешатаных способов доступа к базе не используется. 3. А при чем тут CODEBASE ? 4. Версия КЗК2 тоже не обновлялась уже с полгодика.

при таком зоопарке вк утверждать "Нешатаных способов доступа к базе не используется" просто смешно!!! ну а про доступ - если ограничить доступ к полю период то получешь сабж

Нештатного доступа к базе не используется. 1С++ используется минимально. Все же что-то с сервером. База распределенная. Копирую с удаленного сервера на центральный (на котором проблема) копию периферийки. Периферийка в DBF. На удаленном сервере работает без проблем, на центральном - выдает те же ошибки, что и ЦБ в SQL. То есть, думаю, SQL и права на него можно отбросить, если на DBF-ной базе та же проблема. Саму по себе 1С, кажется, тоже. По крайней мере с базой бухгалтерии (там совсем не используются ВК) аналогичную проблему воспроизвести не удалось. Что ли какая-то несовместимость возникла 1С++ с сервером? Неожиданно и непонятно откуда :-(

+ Самое, по моему, смешное, в том, что не смотря на постоянное вываливание ошибок CODEBASE, 1С не закрывается, и, визуально, работает нормально. Отчеты формируются с виду нормальные. Документы проводятся с, похоже, нормальными движениями.

у одного клиента такая же проблема на ДБФ базе уже достаточно давно. Вылазит на одном виде документов. Проявляется крайне случайным образом. В пределах одной сессии 1С - постоянно при проведении. Кроме ошибок по SPххх ничего не попадалось. Кроме того, что нужно нажать Ок никаких побочных последствий не выявлено.

Заметил сейчас странную вещь. В проблемных базах в папке SYSLOG копятся файлы вида T0.CDX, T0.DBF, T1.CDX, T1.DBF, T2.CDX, T2.DBF, ... После их удаления ошибки перестали вылазить. По крайней мере долбился-долбился в программу - ни разу не выскочила ошибка. Правда файлы опять таки появляются. И довольно быстро.

странное место для темпов ?

Понимаю, что темпы. Но не понимаю, как они туда попали. TEMP и TMP указывают совсем в другое место. Личная папка пользователя в конфигураторе - тоже. Кажется как-то вмешивается то, что я активно пользуюсь файл-флагами, сохраняемыми в SYSLOG с помощью объекта "ТЕКСТ". Сейчас поеду на работу - приеду, буду экспериментировать.

эта ошибка может появляться при формировании каких-либо отчетов (штатно) или выборок (штатно). CODEBASE - это компонент платформы для работы с DBF.

Вот пример, как тама временные файлы... Параметр: /T<путь> - путь к временным файлам 1cv7.exe MODE [ /M | /D<Path> | /U<Path> | /N<Name> | /P<Pass> ], где MODE - режим запуска, может принимать только одно из трех значений : config - режим конфигуратора; enterprise - нормальный (рабочий) режим. monitor - режим "Монитор". следующие ключи опциональны: /M - запуск программы в монопольном режиме; /D - каталог базы данных; /U - рабочий каталог пользователя (каталог из списка пользователей игнорируется); /P - пароль пользователя; /T<путь> - путь к временным файлам /@<ИмяФайла> - для режима конфигуратора с указанием файла пакетного запуска /W - инициализация Web расширения /L - язык интерфейса: ENG - английский, UKR - украинский

Кажется причина выяснена. Каталог временных файлов для 1С размещен на RAM-диске. А так как много места на рам-диске не бывает, сделали скрипт для чистки ненужных файлов во временных каталогах пользователей. Сделали по принципу - если файл во временной папке удалось удалить, значит он уже никому не нужен. Похоже для 1С это не так. У 1С срывает крышу, она начинает раскладывать свои временные файлы в папку SYSLOG и даже, почему-то, на диски клиента, подключенные к терминалу "\tsclientCDocuments and Settings...". На тестовой базе стало работать нормально. Вечерком, когда все полтораста пользователей пойдут спать, обновлю рабочую базу. Завтра отрапортую общественности, эта причина или нет.

Ну вы, блин, даёте. Если бы у вас была файловая база, то её таким методом можно было бы всю удалить. А каталоги пользователей тоже на RAM сложили ? P.S. в NTFS открытый файл удаляется, но остаётся до закрытия.

Ну кто же знал. Последние лет пятнадцать C:TEMP, C:WindowsTEMP, "C:D&SLocal SettingsTEMP" чистил просто "del. /y" и никогда проблем не было. И никакого лишнего удаления временных файлов на NTFS не наблюдалось. К тому же чистка проводилась только при запуске 1С, а не на лету в процессе работы. Но 1Ске и этого хватило :-(

на терминале "del. /y" при запуске?

Нет. Я предпочел вставить очистку временного каталога в 1С ПриНачалеРаботыСистемы, потому что серверов много, в разных городах, и я не могу отслеживать, что там творят админы. Ненадежно получается через планировщик. Переустановил винду местный админ, а я об этом узнаю только тогда, когда 1С начнет падать по причине отсутствия места для временных файлов.

а темпы у всех свои?

У каждого пользователя свой каталог на RAM-диске.