1с не работает с sql 2005
Обновлено: 06.07.2024
3. Также с этой ситуацией пересекается следующая ситуация:
10007066 Запись данных, содержащих колонки типа ХранилищеЗначения
Проблема:
При использовании СУБД MS SQL SERVER при записи объекта базы данных, содержащего несколько колонок типа ХранилищеЗначения, данные для которых получены из файлов, может происходить ошибка
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005и аварийное завершение работы программы.
Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:
S_elect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc
Нюансы: обратите внимание, что ”Стандартные проверки” платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.
1С:Предприятие 8.2. Лицензия на сервер (x86-64)
По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.
Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):
1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель “запрет на фоновые задания” в
момент создания базы.
Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском – вещь в себе – и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять – возможно проблема “уйдет”.
3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться “возврат” к предыдущему состоянию данных
4) снимаем базу с поддержки, выгружаем cf
убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение) убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение)
1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FROM dbo.Config WHERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.
можно попробовать и более радикальный шаг здесь:
удаляем (в менеджмент консоли) в базе данных таблицу “config”
D_rop TABLE [dbo].[Config]
5) делаем “загрузить конфигурацию” (не объединение) из cf
после этого проверяем, проблема уходит.
6) Ошибка :"Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005"
Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)
В глобальный модуль (процедура ПриНачалеРаботыСистемы()) необходимо добавить код:
Если это не поможет - смотрите другие варианты решения проблемы здесь.
Ошибки при загрузке данных 1С в базе SQL <в начало>
SQL State: 42000
Message: [Microsoft][ODBC SQL Server Driver][SQL Server] Incorrect syntax near 'HOLDLOCK'. If this is intended as a part of a table hint, A WITH keyword and parenthesis are now required.
Недопустимое состояние транзакции.
Необходимо установить compatibility level 80 (режим совместимости) в свойствах базы данных.
Требуется MS SQL Server 6.5 + Service Pack 5a или более старшая версия <в начало>
Порядок сортировки отличается от системного при загрузке базы 1С в формате SQL на WIndows 7 <в начало>
Необходимо допатчить bkend.dll 0018A79D: 75 EB для отключения проверки порядка сортировки либо опять же использовать секретный релиз платформы v77.27.1
Примечание к описанию секретного релиза, добавляем public чтобы не было ошибки: GRANT VIEW SERVER STATE TO public
Попробуйте заменить оригинальную BkEnd.dll на пропатченную Bkend.dll
SQL сервер не существует или доступ запрещен <в начало>
Вот такая ошибка может появиться на клиентском компьютере при запуске 1С.
Расскажу что нужно проверить и настроить
Если Вы используете SQL Express, то он именуется как ИмяСервера\SQLEXRESS, не забывайте об этом.
Что нужно сделать на сервере:
Зайти в SQL Server Configuration Manager.
В конфигурации сервера и в клиентских протоколах оставить включенным только протокол TCP/IP.
Убедиться в том, что включена не только служба SQL Server, но и SQL Server Browser (Обозреватель SQL Server).
Если не помогает - отключить или проверить Брандмауэр.
В протоколах убрать динамический порт и выставить TCP-порт 1433.
После этого остановить службы и запустить заново.
На клиенте:
Открыть Пуск - Настройка - Панель управления - Администрирование - Источники данных (ODBC) - Системный DSN.
Там добавить SQL Server, ввести имя (например, Client), указать сервер (SERVER\SQLEXPRESS или именованный SQL Server), нажать Далее, в настройке SQL клиента снять флажок "динамически определить порт" и указать порт 1433.
Можно сразу же и проверить доступность сервера:
Все, пробуем запускать 1С еще раз.
Если это не помогло - попробуйте вместо имени сервера (допустим, Server01, если экземпляр не именованный) ввести в параметрах соединения 1С IP, например 192.168.0.2.
Если после этого начались какие-то другие ошибки, значит Вы сделали все правильно :)
Не удалось выделить новую страницу для базы данных <в начало>
Вот такая ошибка может появиться при выполнении обмена, либо в процессе работы:
Физически увеличить размер файла базы данных также не получится, так как Вы используете, вероятно, SQL Express.
Объем базы данных для версии Express (для 2005 и 2008 SQL Server) не может превышать 4 Гб. 64-разрядная версия 2008 R2 SQL Server позволяет работать с базой до 10 Гб.
Таким образом, необходимо либо обрезать базу, либо использовать другую версию SQL Server. Developer Edition вполне можно приручить для работы нескольких пользователей на Winows XP или другой 32-разрядной системе.
1. Для этого выгрузил данные: конфигуратор-> выгрузить данные
2. Создал пустую папку "absql" для sql базы, закинул туда папку "usrdef", создал пока на том же диске внутри папки "absql" папку "log".
3. Зашел в SQL Server Manegement Studio 2005, раскрыл конфигурацию, в вкладке "базы данных" -> создать базу данных/ имя базы "absql" / владелец <по умолчанию> (по умолчанию владелец базы SERVER1C\Администратор т.к. имя компа server1c, имя учетной записи администратор).
4. Указал размер базы как написано в 2-2,5 раза больше чем в dbf, log файл 25% от базы. Указал пути к папке где будет храниться база e:\absql; путь к log'y e:\absql\log.
5. В окне 1с 77 нажал "добавить", указал путь к базе e:\absql.
6. Зашел в конфигураторе под своим паролем. В Администрирование\параметры базы данных sql поставил следующее: сервер - SERVER1C, база данных - absql, пользователь - Администратор, пароль - 123465. При нажатии "ОК" выскакивавет ошибка: SQL state: 28000 native: 18456 message: [microsoft][odbc SQL server driver][sql server]Пользователю "Администратор" не удалось войти в систему. Следом окошко: Соединение с сервером базы данных установить не удалось. Указанная адресная информация может быть ошибочной! Сохранить адресную информацию? да / нет. Соответственно далее нельзя загрузить базу так как вылетает та же ошибка.
Пробовал в сервер ставить: \\server1c;
база данных: пробовал указать вместе с путем к базе;
в пользователь писал: \\server1c\Администратор, пробовал захоть через sa и пустой пароль.
Где я ошибся или что сделал не правильно?
1 С для SQL версия 7.70.250
SQL Server 2005 v.9.00.1399.00
компоненты доступа к данным MDAC v.2000.086.3959.00
Служба ODBC вроде бы установлена, по крайней мере можно найти приложение через поиск.
ОС Microsoft Windows 2003 Server R2.
В sql server manegemant studio в вкладке "безопастность" стоит галочка "проверка подлинности через sql server и windows". Владельцем всех баз является "server1c\администратор"
У кого есть какие предложения?
1. 1С 7.7 требует для коннекта SQL-уч.запись (не Windows)
2. Эта уч. запись должна быть owner (dbo) базы.
===========
ну а SA - это круто, все хакеры плачутЬ.
Select * from master.sysprocesses where dbid=DB_ID('my_base') видит только мой 1с-овский коннект, если кто-то подключен к базе.
Вроде как sysprocesses является устаревшей.
Хорошо, на другом форуме мне посоветовали select * from sys.dm_exec_requests.
1. "Пользовательский процесс" базу в этом случае заблокировать не может. Это контролируемо. Единственный "пользовательский процесс" - это сам аппликуха 1С, а я её контролирую.
Еще раз порядок действий:
1.1 1С запускаем монопольно и что-то делаем большое, например "тестирование и исправление". Закрываем 1С.
1.2 Через некоторое время пытаемся зайти через 1С монопольно. Иногда выдаёт любимую ошибку "База данных уже открыта, и одновременно к ней может обращаться только один пользователь".
Стопудово перед этим заходом никаких пользовательских процессов там нет, смотрел всем чем угодно. Да и откуда они? Сама семерка 1С никаких фоновых процессов не делает.
При этом в п.1.2 если зайти не монопольно, таких проблем не возникает.
sp_who2 еще не пробовал, попробую для очистки совести.
Before you set the database to SINGLE_USER, verify the AUTO_UPDATE_STATISTICS_ASYNC option is set to OFF.
When set to ON, the background thread used to update statistics takes a connection against the database,
and you will be unable to access the database in single-user mode.
To view the status of this option, query the is_auto_update_stats_async_on column in the sys.databases catalog view.
If the option is set to ON, perform the following tasks:
Set AUTO_UPDATE_STATISTICS_ASYNC to OFF.
Check for active asynchronous statistics jobs by querying the sys.dm_exec_background_job_queue dynamic management view.
Проблема-то не в том, что база остается в single_user, это фигня, сама же 1С потом при следующем заходе этот single_user сбрасывает. Проблема в том, что не всегда может с первого раза зайти монопольно, а это плохо для всяческих регламентных работ, которые запускают 1С монопольно и автоматом в батнике. Выдало ошибку, и всё, встало раком
Понятно, что 1С - это не совсем вопрос для этого форума. Вопрос в том, что эту проблему вызвало и как это отловить.
Про "фоновый процесс сброса грязных страниц" - это я процитировал из мануала к патчу 1С для работы с SQL 2005-2012 безвестного аффтара. Более этот термин цитировать не буду.
Чтобы закрыть левый вопрос про single_user, еще раз по шагам приведу действия:
По поводу AUTO_UPDATE_STATISTICS_ASYNC - спасибо, посмотрел в пропертях базы, оно у меня в off. По дефолту.
Еще раз последовательность, детализованно.
1) 1С чегой-то делает монопольно, долго и упорно. Какой-то пересчет с большой модификацией данных. Отработала. Вышла.
2) Смотрю базу. Она в multi_user (про F5 я в курсе, не такой уж ламер). Никаких процессов не висит.
Кстати, сейчас еще посмотрел в этот момент "EXEC sp_who2" - ничего на моей базе нет. И "SELECT * FROM sys.dm_exec_background_job_queue" - ни одного процесса.
3) Запускаем опять 1С монопольно. Ругаеццо про невозможность войти монопольно и ждет нажатия OK. Жмём. Выходит.
4) Смотрим базу. Она в single_user.
5) Если 1С опять запустить - что монопольно, что разделенно, она успешно входит. Предыдущий single_user при этом сбрасывается. Но это уже совсем другая история.
Последовательность запросов 1С генерит в (3) одну и ту же, что при успешном, что при неуспешном входе. Никаких процессов и блокировок обнаружить не удалось.
Гипотеза может быть одна. У 1С, когда она устанавливает single_user, слишком маленький таймаут. И она отваливает по таймауту, хотя и вошла успешно в single_user. И если запущена из батника, то останавливает батник, ожидая OK.
Это просто баг клиентского приложения. Что то она там переключает туда-сюда, ИМХО видимо переводит базу в мульти, а где то в своих файлах сохраняет, что оставила в сингл.
Решать вопрос нужно на форумах по 1С
Но это же не бага сиквела, типа, что ему 1С посылает команду, а он не выполняет?
С моим удовольствием. Management \ SQL Server Logs. Лог примерное за период, когда сегодня тестил. Причем без всяких костылей. Ошибка произошла (по логу 1С) около 15:53.
Почему вы ничего не видите в sys.dm_exec_requests.
Потому что спид51 ничего не делает. Прицепился и висит, ничего не выполняя.
Да бог с тобой:
1) Сервер написал в 10:49:38, что готов принимать клиентские подключения, процесс "Сервер"
2) Далее, в те же секунды запустил базы данных.
3) Потом в 10:49:40 писал ворнинги про протоколы и прочую фигню.
4) В 10:49:51 написал "восстановление завершено"
5) А вот в 10:52:04 уже вошел в базу монопольно, это я запустил "тестирование и восстановление".
Читайте также: