Odbc ошибка подключения к бд access

Не удается использовать интерфейсы Access ODBC, OLEDB или DAO за пределами приложений Office «нажми и запускай»

Симптомы

При попытке создать DSN ODBC для драйверов, предоставляемых Microsoft Access администратором ODBC источников данных, попытка завершается ошибкой. Эта проблема возникает, если вы используете установку Office «нажми и запускай» (C2R), которая не предоставляет ядро СУБД Access за пределами пузырька виртуализации Office. В зависимости от версии Office при выполнении этой операции могут возникнуть следующие проблемы:

Драйверы ODBC, предоставляемые ACEODBC.DLL, не перечислены в диалоговом окне « Выбор драйвера».

Вы получите сообщение об ошибке «В настоящее время операционная система не настроена для запуска этого приложения».

Вы получите сообщение об ошибке «Не удается загрузить odbcji32.dll».

Вы получите сообщение «Драйвер этого имени DSN пользователя не существует. Его можно удалить только». Сообщение об ошибке вместе с платформой с отображением N/A.

• Драйвер Microsoft Access (*.mdb, *.accdb)
• Текстовый драйвер Microsoft Access (*.txt, *.csv)
• Драйвер Microsoft Excel (*.xls, *.xlsx, *.xlsm, *.xlsb)

Кроме того, при попытке определить подключение OLEDB из внешнего приложения (которое выполняется за пределами Office) с помощью поставщика OLEDB Microsoft.ACE.OLEDB.12.0 или Microsoft.ACE.OLEDB.16.0 OLEDB при попытке подключения к поставщику возникает ошибка «Поставщик не найден».

Причина

Установка Office «нажми и работай» выполняется в изолированной виртуальной среде в локальной операционной системе. Некоторые приложения за пределами Office могут не знать, где искать установку в изолированной среде.

Решение

Начиная с Приложения Microsoft 365 для корпоративной версии 2009, была завершена работа по выходу ACE из пузырька виртуализации C2R, чтобы приложения за пределами Office могли находить интерфейсы ODBC, OLEDB и DAO, предоставляемые ядром СУБД Access в установке C2R.

Используйте следующую таблицу, чтобы понять, необходимы ли дополнительные компоненты для доступа к этим интерфейсам в вашей среде:

• Распространяемый компонент ядра СУБД Microsoft Access 2016 не предоставляется в качестве рекомендуемой установки, так как в ядре СУБД Access 2016 и Приложения Microsoft 365 используется один и тот же основной идентификатор версии (16.0), что может привести к непредвиденным событиям. Параллельное обнаружение Office также не позволит продолжить установку, если этот сценарий обнаружен.

Дополнительные сведения о создании подключений ODBC

Все экземпляры Office «нажми и запускай» не могут создавать имена источников данных компьютера или системы в приложении Office или у администратора ODBC источников данных.

Источник

PRB: ошибка 80004005 «Ядро СУБД Microsoft Jet не может открыть файл «(неизвестно)»

Симптомы

При использовании объектов данных ActiveX (ADO) или ODBC для подключения к базе данных Microsoft Access может появиться следующее сообщение об ошибке:

Причина

Это сообщение об ошибке может быть описано по нескольким причинам.

• Учетная запись, используемая microsoft Internet Information Server (IIS) (обычно это IUSR), не имеет правильных разрешений Windows NT для файловой базы данных или папки, содержащего файл.
• Файл и имя источника данных помечены как монопольные.
• Для другого процесса или пользователя открыта база данных Access.
• Ошибка может быть вызвана проблемой делегирования. Проверьте метод проверки подлинности (базовый и NTLM), если он есть. Если в строке подключения используется универсальное соглашение об именовании (UNC), попробуйте использовать обычную проверку подлинности или абсолютный путь, например C:MydataData.mdb. Эта проблема может возникнуть, даже если UNC указывает на ресурс, локальный для компьютера IIS.
• Эта ошибка также может возникать при доступе к локальной базе данных Microsoft Access, связанной с таблицей, в которой таблица находится в базе данных Access на сетевом сервере.

Решение

Следующие элементы соответствуют предыдущему списку причин:

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

Если используется сетевой путь к базе данных (UNC или сопоставленный диск), проверьте разрешения на общую папку, файл и папку.

Убедитесь, что файл и имя источника данных (DSN) не помечены как монопольные.

«Другим пользователем» может быть Microsoft Visual InterDev. Закройте все проекты Visual InterDev, содержащие подключение данных к базе данных.

Упростить. Используйте системное имя DSN, использующее локальную букву диска. При необходимости переместите базу данных на локальный диск для тестирования.

Ссылки

Чтобы проверить наличие сбоев доступа к файлам, используйте Windows NT монитора файлов. Чтобы скачать монитор файлов, см. раздел Windows Sysinternals.

Источник

Вот как вы можете исправить проблемы ODBC в Windows 10

ODBC весьма полезен для процедур доступа к приложениям, особенно для профессиональных пользователей. И, похоже, существует множество проблем для пользователей Windows 10, которые либо перешли с Windows 7, либо обновили свою версию Windows 10 до последней версии.

Если вы один из них и у вас есть определенные проблемы с ODBC в Windows 10, проверьте решения ниже.

Как исправить проблемы ODBC в Windows 10

1. Удалить SMBv1 и включить SMBv2/SMBv3)
2. Проверьте брандмауэр Windows и Защитник Windows
3. Обновление драйверов
4. Откат к предыдущей версии Windows

Решение 1. Удалите SMBv1 и включите SMBv2/SMBv3)

Некоторые пользователи решили проблему, отключив SMBv1 и включив SMBv2 или SMBv3. Это можно сделать различными способами, начиная с PowerShell или редактора реестра. Последний способ быстрее и проще, но может негативно повлиять на ваш компьютер при неправильном использовании. Поэтому, прежде чем выполнять следующие шаги, обязательно сделайте резервную копию вашего реестра.

Вот как отключить SMBv1 и включить SMBv2/SMBv3:

1. В строке поиска Windows введите regedit и откройте редактор реестра.
2. Перейдите в ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParameters .
   
3. Щелкните правой кнопкой мыши пустое пространство и создайте новый Dword, назовите его SMB1 и установите его значение равным 0.
4. Щелкните правой кнопкой мыши на пустом месте и создайте новый Dword, назовите его SMB2 и установите его значение равным 1.
5. Закройте редактор реестра и перезагрузите компьютер.

Сделайте это на каждой уязвимой машине и не забудьте перезагрузить ее, чтобы изменения вступили в силу.

• ЧИТАЙТЕ ТАКЖЕ: отключите SMBv1 в Windows с помощью этих быстрых методов

Решение 2. Проверьте брандмауэр Windows и Защитник Windows

Некоторым пользователям удалось решить проблему, просто добавив белый список или временно отключив брандмауэр Windows и включив Защитник Windows. Это долгосрочное решение, но оно того стоит. Если у вас уже есть сторонний антивирус, попробуйте объединить его с нативным антивирусом.

После этого перезагрузите компьютер и попробуйте снова получить доступ к приложению ODBC.

Решение 3 – Обновление драйверов

В случае, если вы используете 32-битный Office на 64-битной машине через ODBC, вам потребуется некоторая перенастройка, чтобы избежать ошибок драйвера. Или, скорее, доступ к версии ODBC32 вместо стандартной 64-битной версии, представленной в архитектуре x64.

Вот где его найти и как его запустить:

1. Перейдите к C: WindowssysWOW64odbcad32.exe и запустите его. Это 32-битный администратор источника данных ODBC.
2. Попробуйте применить драйверы снова.
   
3. После того, как вы применили драйверы, перезагрузите компьютер.

Решение 4 – Откат к предыдущей версии Windows

Как говорили многие из затронутых пользователей, проблема возникла после того, как они обновили Windows 10 до версии 1803. То же самое можно применить к 1809. И вместо того, чтобы ждать, пока Microsoft решит проблемы ODBC в их текущем выпуске, мы скорее предлагаем откат до предыдущей версии, где сервис был полностью функциональным.

• Читайте также: исправлено: синий экран после отката Windows 10

Вот как перейти к предыдущей версии Windows 10:

1. Откройте Настройки .
2. Выберите Обновление и безопасность .
3. Выберите Восстановление на левой панели.
4. Нажмите « Вернуться к предыдущей версии Windows 10 ».
   
5. Нажмите Начало работы и следуйте инструкциям.

Источник

Сбой администратора источника данных ODBC при добавлении системного имени DSN

Симптомы

Рассмотрим следующий сценарий.

• Вы используете физический компьютер, на котором установлен компонент Microsoft Access Database Engine 2016.
• Аппаратное ускорение включено.
• Версия ACEODBC.dll 16.0.4378.1000 (KB3114378) или более поздняя.
• В администраторе источника данных microsoft Open Database Connectivity (ODBC) (Odbcad32.exe) добавьте имя системного источника данных (DSN), использующее драйвер Microsoft Access (*.mdb или *.accdb).

В этом сценарии Odbcad32.exe аварийно завершается.

Обходной путь

Чтобы обойти эту проблему, отключите аппаратное ускорение с помощью раздела реестра DisableHardwareAcceleration , как показано ниже.

Эта проблема была зарегистрирована и изучается. Мы рекомендуем использовать раздел реестра только для отключения аппаратного ускорения во время создания имени DSN и повторно включить аппаратное ускорение при необходимости.

Точно следуйте всем указаниям из этого раздела. Внесение неправильных изменений в реестр может привести к возникновению серьезных проблем. Прежде чем изменять его, создайте резервную копию реестра для восстановления наслучай возникновения проблем.

Закройте все приложения Microsoft Office.

Запустите редактор реестра:

• Windows 10: перейдите в меню «Пуск«, введитеregedit в поле поиска, а затем выберитеregedit.exeв результатах поиска.
• Windows 8 или Windows 8.1: переместите указатель мыши в правый верхний угол, выберите «Поиск«, введитеregedit в текстовом поле поиска, а затем выберитеregedit.exe в результатах поиска.
• Windows 7: Выберите «Пуск», введите regeditв поле «Пуск поиска», а затемregedit.exeв результатах поиска.

Найдите и выделите следующий подраздел реестра:

HKEY_CURRENT_USERSoftwareMicrosoftOffice16.0CommonGraphicsDisableHardwareAcceleration

В меню «Правка » наведите указатель мыши на пункт «Создать», а затем выберите значение DWORD.

Введите DisableHardwareAcceleration и нажмите клавишу ВВОД.

В области сведений нажмите и удерживайте (или щелкните правой кнопкой мыши) DisableHardwareAcceleration, а затем выберите «Изменить».

В поле данных «Значение » введите 1 и нажмите кнопку » ОК».

Источник

Подключение к БД Access. Источник данных не найден и не указан драйвер по умолчанию.

Всем почти летней весенней субботы!-)

Написал обработку на свом компе, в начальной своей задаче она подрубается к бд access для последующего изъятия оттудова данных, все прекрасно работает. Перенес на комп с Win Server 2008 и все встало.

Сначала была проблема с созданием COMОбъект(«ADODB.Connection»), о чем вопрошал на форуме на прошлой неделе.

Ладно, эту проблему разрешил, но следующая настигла буквально на следующей строчке.

При попытке Connection.Open(СтрокаПодключения) выходит ошибка «Произошла исключительная ситуация (Microsoft OLE DB Provider for ODBC Drivers): [Microsoft][Диспетчер драйверов ODBC] Источник данных не найден и не указан драйвер, используемый по умолчанию.

Собственно, если загуглить эту ошибку, ответов очень много, в том числе и на данном форуме, но 90% из них касаются подключения к базам MS SQL. Мне из этого ничего не помогло.

Теме не менее, что было предпринято и проделано:

1. Скачан свежий MDAC и переустановлен.

2. Дважды скачаны и установлены драйверы для Access

3. Дважды переустановлен Office

Ничто из этого не помогло ни разу.

Операционка 64 бит, офис 32 бит, 1С 32 бит

На ноуте, где тестировалась эта же обработка, расклад по битности такой же, только ОС Windowc 7.

В администраторе источников данных ODBC все один в один, перепроверил несколько раз.

Что еще предпринять, даже предположить не могу. )

Источник

27.04.19 — 14:13

1 — 27.04.19 — 14:16

(0) для работы с Access не нужен Microsoft OLE DB Provider for ODBC Drivers,

код покажи

2 — 27.04.19 — 14:18

(0) там сам вызов в обработке надо переделать

3 — 27.04.19 — 14:19

4 — 27.04.19 — 14:20

(2) простите, не понял вас

5 — 27.04.19 — 14:21

(2) Повторюсь, на моем-то компе работает, базы и там и там файловые, с серваком напрямую работаю, не через RDP даже

6 — 27.04.19 — 14:29

7 — 27.04.19 — 14:39

(3)[СтрокаПодключения = «Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=» + ФайлБазы;]

забудь как страшный сон

https://www.connectionstrings.com/access-97/

Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:mydatabase.mdb;

8 — 27.04.19 — 14:46

(6) (7) Господа, увы. В обоих случаях ошибка «Не удается найти указанный поставщик. Вероятно, он установлен неправильно».

9 — 27.04.19 — 14:47

По правде, я перепробовал штук 10 разных строк подключения.

10 — 27.04.19 — 14:48

(8) ну положи руки по каток — у всех работает

11 — 27.04.19 — 14:52

«Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=» + ФайлБазы; у меня на ноуте тоже работает и наверное «Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:mydatabase.mdb;» сработает (не проверял).

Пойдук кстати проверю, дабы руки руки на каток не класть-)

12 — 27.04.19 — 14:55

(11) открой реестр windows, посмотри чего там написано, скопипасть сюда.

13 — 27.04.19 — 15:05

(10) Все же мои руки непричем: строка Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:myFoldermyAccessFile.accdb на моем компе отработала на ура.

14 — 27.04.19 — 15:05

(13) отработала на ноуте, но не на серваке

15 — 27.04.19 — 15:06

16 — 27.04.19 — 15:09

(15) так тоже пробовал — ошибка как в теме сабжа…

17 — 27.04.19 — 15:14

(12) а что с реестром-то делать? Открыл, в правой части пусто.

18 — 27.04.19 — 15:20

(16) так вы DBQ большими буквами фигачите, сервер такого не прощает.

19 — 27.04.19 — 15:29

20 — 27.04.19 — 15:34

(17) ну нашли там Driver={Microsoft Access Driver эту строчку?

21 — 27.04.19 — 15:44

22 — 27.04.19 — 16:22

(20) Нет, не вижу

23 — 27.04.19 — 16:25

Имхо проблема в админе и правах, или в чем то не доустановленном или ошибках в «комп с Win Server 2008».

24 — 27.04.19 — 16:30

25 — 27.04.19 — 16:31

26 — 27.04.19 — 16:31

(23) (24) (25) Благодарю.

27 — 27.04.19 — 16:45

28 — 27.04.19 — 16:46

29 — 27.04.19 — 16:50

(28) Русские имена таблиц болт

30 — 27.04.19 — 16:53

31 — 27.04.19 — 16:53

(7) на самом деле тут может быть проблема. Движок Jet 4.0 изымался из висты и из каких-то младших версий MDAC (кажется из MDAC 2.8, хотя могу ошибаться), поэтому то что установили MDAC — еще не гарантирует, что оно будет работать. Такого рода проблемы у меня когда-то давно были. С учетом того что (0) нигде не указывает, что у него W2008 R2, возможно, у него те же проблемы, что и с вистой — т.е. 32-битный Jet 4.0 отсутствует, а поставить он его не может потому что не знает как. Поэтому же не работают и ODBC-драйверы — потому что для работы с MDB им по-любому нужен движок Jet, а его нет в системе.

32 — 27.04.19 — 16:56

(31) Винда 2008 R2.

33 — 27.04.19 — 16:56

34 — 27.04.19 — 17:00

(32) Вообще немного странно, потому что R2 — это больше «семерка», чем «виста», и Jet 4.0 32-битный в нем должен быть.

35 — 27.04.19 — 17:01

Сервер 1С точно 32 бит?

36 — 27.04.19 — 17:02

37 — 27.04.19 — 17:03

(35) База файловая, 1С-ка 32 битная.

38 — 27.04.19 — 17:03

но вам тогда придется поменять строку подключения

39 — 27.04.19 — 17:04

(36) Проще Microsoft SQL Server Express поставить и через него уже

40 — 27.04.19 — 17:05

(39) Оттуда из строчку подключения дернуть из SQL Server Management Studio

41 — 27.04.19 — 17:05

(39) а причем тут скуль? Это же разные вещи — формат скуля и настольный формат ACE (ранее MDB)

42 — 27.04.19 — 17:06

(41) Он требуемое в комплекте поставит в т.ч. для доступа к mdb ))

43 — 27.04.19 — 17:06

44 — 27.04.19 — 17:06

другое дело, что скуль до кучи и этот движок может притащить с собой, но я в этом не уверен

45 — 27.04.19 — 17:07

(43) Сейчас гляну

46 — 27.04.19 — 17:07

(39) На серваке 60 баз-) отдельно одну базу не вариант на него ставить, а 60 на 10 гб не станут-)

47 — 27.04.19 — 17:08

Попробуй все же через mdb-export вытащить как в (33), если все ок то и нафик, зато решение универсальное и даже под linux работает, если 1С там

48 — 27.04.19 — 17:09

(47) тащить через командную строку?

49 — 27.04.19 — 17:10

(48) Дык проверенное решение.

Можно конечно извратиться и на основе исходников ВК наваять но нафига?

50 — 27.04.19 — 17:11

(49)не, я уточняю-)

51 — 27.04.19 — 17:12

(45) У меня станцевало вот так

Provider=Microsoft.ACE.OLEDB.12.0;Data Source=»D:DocumentsProgrammingTradeDBe-scales.mdb»

52 — 27.04.19 — 17:13

с 32-битным движком. Вот только что специально установил по ссылке в (36).

53 — 27.04.19 — 17:16

от старенького Jet4 отличается тем, что все исключения, касающиеся базы — на английском, а не на русском. А так разницы особой не вижу.

54 — 27.04.19 — 17:16

(51) у меня на ноуте с Виндой 7 сегодя тоже под этой стройкой станцевало на ура…

а на этом гребаном серваке болт: Произошла исключительная ситуация (ADODB.Connection): Не удается найти указанный поставщик. Вероятно, он установлен неправильно.

55 — 27.04.19 — 17:16

(33)+ Уточнение что внутри mdb была кириллица cp1251 а после экспорта в csv там utf8

56 — 27.04.19 — 17:18

(55) внутри mdb cp1251? Это, наверно, какой-то совсем старый mdb, потому что уже в формате Access 2000 они все шли с UTF-16 Unicode. Я других и не видел тыщу лет.

57 — 27.04.19 — 17:19

(54) а вы движок перед этим по ссылке поставили? Какой битности? Надо было 32-битный, раз у вас 1С файловая и 32-битная.

58 — 27.04.19 — 17:21

(57) обязательно. И комп (сервак) перезапустил. 32 битный, 64 даже не ставится, пишет не предназначен для данного ПО.

59 — 27.04.19 — 17:21

(56) А хрен его знает что там внутри, может и UTF16.

Но на выходе UTF8

60 — 27.04.19 — 17:23

(59) ну если просто открывать на просмотр (например фаром по F3) файл MDB от Access 2000-2003, то видно, что строки там лежат в UTF-16 LE. Собственно, она нативная для современных виндов, так что удивительного тут мало.

61 — 27.04.19 — 17:28

(58) не предназначен? Вы хотите сказать, что сервер у вас 32-битный?

Тогда попробуйте сделать вот что. Создайте на нем файл 111.udl и запустите его на исполнение двойным щелчком.

Что вы увидите на закладке «Поставщик данных»?

62 — 27.04.19 — 17:28

63 — 27.04.19 — 17:32

+ (61) как вариант, вы можете вообще полностью сконструировать и протестировать вашу строку в этом UDL-файле. А потом просто зайти в него и скопировать оттуда данные или написать в строке соединения ADODB.Connection

FILE NAME=[путь]111.udl

64 — 27.04.19 — 17:42

65 — 27.04.19 — 18:06

(64) а почему тогда у вас 64-битный инсталлятор движка не запускается на выполнение, как вы пишете в (57)?.. Ладно. Тогда попробуйте сделать следующее. Зайдите в 1С, зайдите в меню Файл, Открыть. Выберите в диалоге открытия Тип файлов — Все файлы (*.*). Найдите ваш 111.udl, щелкните по нему правой кнопкой и выберите последний пункт, «Свойства». Что теперь видите в закладке «Поставщик данных»?

66 — 27.04.19 — 18:09

67 — 27.04.19 — 18:13

А вот и момент истины. Смотрите. У вас есть аж три (!) 32-битных движка для доступа к Access файлу. Это Microsoft Office 12.0 Access Database Engine, Microsoft Office 16.0 Access Database Engine и Microsoft Jet 4.0 OLE DB Provider. Вы можете проверить их по одному. Выбирайте каждый, заходите в закладку Соединение, прописывайте там путь к файлу и нажимайте Проверить соединение.

68 — 27.04.19 — 18:14

начните с Jet 4.0, там можно выбрать mdb-файл через диалог. В более новых надо прописывать строку пути руками.

69 — 27.04.19 — 18:37

(68) Результаты следующие: Microsoft Jet 4.0 OLE DB Provider и Microsoft Office 12.0 Access Database Engine — проверка соединения за вершилась успешно.

Попытка проверить соединение от Microsoft Office 16.0 Access Database Engine вызывает исключительную ситуацию с закрытием 1С.

70 — 27.04.19 — 18:54

(69) ну а теперь все очень просто. Берете любой пример где соединение завершилось успешно и жмете ОК или Применить. После этого внутри файла 111.udl вы имеете рабочую строку соединения, которая гарантированно подключает (вы же проверяли). Этот файл — текстовый, вы можете скопировать из него инфу. Либо можете не копировать, а сделать как написано в конце (61). Пробуйте.

71 — 27.04.19 — 19:01

72 — 27.04.19 — 19:02

(71) Вы кликаете откуда, из винды? Зря. Зайдите в 1С, Открыть и Свойства

73 — 27.04.19 — 19:03

Здесь прикол в том, что когда вы кликаете из винды, вы это делаете из 64-битной среды исполнения. Там все другое. И движков этих — НЕТ. А когда вы делаете то же самое из 1С, вы делаете это из 32-битной среды исполнения.

74 — 27.04.19 — 19:06

75 — 27.04.19 — 19:07

Пробую в 1С обработку, опять ошибка…

76 — 27.04.19 — 19:07

Как выглядит код обработки?

77 — 27.04.19 — 19:08

вот сейчас, после того как скопировали данные

78 — 27.04.19 — 19:10

79 — 27.04.19 — 19:12

Строка записана верно. Я бы оставил второй вариант и проверял его.

80 — 27.04.19 — 19:13

(79) Проверяю, но ошибка таже. Фууххх…

81 — 27.04.19 — 19:14

тогда вариантов пока нет

82 — 27.04.19 — 19:16

Если операционка x86_64 то может быть такой прикол что тонкий клиент 1С x86 в файловой.

Но еще стоит платформа 1C x86_64 опубликованная на апаче/iis и в ней &НаСервере вполне 64 бит ))

83 — 27.04.19 — 19:18

(82) Отдельная одна база опубликована, но не эта.

84 — 27.04.19 — 19:19

А как узнал что платформа 1С x86 а не x86_64 ?

85 — 27.04.19 — 19:20

&НаСервере
Процедура ИнфоНаСервере()
    
    Сообщить("На сервере------------------------------------------------------");
    СисИнфо = Новый СистемнаяИнформация;
    Сообщить("ВерсияОС: "+СисИнфо.ВерсияОС);
    Сообщить("ТипПлатформы: "+СисИнфо.ТипПлатформы+", ВерсияПриложения: "+СисИнфо.ВерсияПриложения);
    Сообщить("Процессор:"+СисИнфо.Процессор+", Память: "+СисИнфо.ОперативнаяПамять);
КонецПроцедуры

&НаКлиенте
Процедура ОбработкаКоманды(ПараметрКоманды, ПараметрыВыполненияКоманды)
    ИнфоНаСервере();
    
    Сообщить("На клиенте------------------------------------------------------");
    СисИнфо = Новый СистемнаяИнформация;
    Сообщить("ВерсияОС: "+СисИнфо.ВерсияОС);
    Сообщить("ТипПлатформы: "+СисИнфо.ТипПлатформы+", ВерсияПриложения: "+СисИнфо.ВерсияПриложения);
    Сообщить("Процессор:"+СисИнфо.Процессор+", Память: "+СисИнфо.ОперативнаяПамять);
КонецПроцедуры

86 — 27.04.19 — 19:24

87 — 27.04.19 — 19:27

А сервер то перезагружал после установки (36) ?

88 — 27.04.19 — 19:29

89 — 27.04.19 — 19:33

Вот только почему функция СисИнфо.ВерсияОС вернула Microsoft Windows 7?? А Компьютер — свойства — показваете Server 2008 r2?… Удивительно.

90 — 27.04.19 — 19:38

(89) И на сервере и на клиенте «вернула Microsoft Windows 7» ?

91 — 27.04.19 — 19:39

(90) Ага. Ничё непонимаю-)

92 — 27.04.19 — 19:40

(91) А 1С случаем не в «режиме совместимости» запускаете?

93 — 27.04.19 — 19:42

94 — 27.04.19 — 19:47

(93) Глянул на всякий, нет, не в режиме совместимости

95 — 27.04.19 — 19:49

Ну тогда уй его знает, сервак переустановить точно должно помочь. Но не 100% ))

96 — 27.04.19 — 19:52

97 — 27.04.19 — 19:57

98 — 27.04.19 — 21:14

Спасибо, но вообще все это предельно странно. Особенно странно то, что тест OLEDB-соединения в соответствующей среде проходит успешно. Была бы угроблена винда — не проходил бы тест…

99 — 27.04.19 — 21:16

(98) Может там учебная версия 1С в которой COM-соединения порезаны ))

100 — 27.04.19 — 21:16

100