Пример реализации хранения файлов и изображений во внешней СУБД MS SQL
Интеграция - Внешние источники данных
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Преамбула
До сего момента в нашей организации в самописной конфе использовался стандартный механизм из типовой торговли - ХранилищеДополнительнойИнформации, но когда объем базы достиг 48 Гб (размер прикрепленных файлов - 35 Гб) база стала ощутимо тормозить.
Была проведена ревизия хранимых файлов: конечно выяснилось, что пользователи крепили информацию чуть ли не в BMP формате с глубиной цвета в 24 бит, но сути это не меняло - основная масса документов была в нормальном виде и их размер был обусловлен большим количеством отсканированых листов. Анализ SQL Profiler показал, что никаких ощутимо тяжелых запросов на базу не идет, тем не менее счетчики производительности дисковых массивов показывали 70% очередь в обычном режиме и 97-100% при работе регламентных заданий. Была выявлена закономерность, что когда работал обмен с головной организацией с которым приходило большое количество сканированных файлов то у пользователей наблюдалось зависание 1С. Что и натолкнуло на мысль разнести хранимые в системе файлы и сканы документов с данными конфигурации.
Действо
Сначала был рассмотрен вариант разнесения данных конфигурации и хранимых файлов по разным файловым группам внутри той же базы, что позволило бы вынести таблицу ХранилищаДополнительнойИнформации на отдельный дисковый массив. Это увеличило бы производительность базы, но не решило бы проблему быстро растущей базы, которая за последние 3 месяца прибавила 15Гб. Такую базу сложнее обслуживать и поддерживать тестовые базы, которых у нас 6 шт.
В итоге было принято решение вынести непосредственно хранимые файлы в отдельную базу с доступом к ней через интерфейс ADO, минуя сервер приложений, чтобы дополнительно разгрузить и его. В справочник ХранилищеДополнительнойИнформации было добавлено два реквизита для хранения размера файла и для хранения UID, который бы использовался для поиска данных во внешней базе.
На MS SQL была создана база состоящая из 1 таблицы:
FileTable
- FileID - char(36), по данному полю желательно создать индекс.
- Object -varbinary
Имена могут быть другими, но тогда придется подправить запросы в предлагаемой конфигурации.
Для указанной базы был создан отдельный пользователь с правами dbo, такой вариант лучше с точки зрения безопасности. Дополнительно база была создана на другом дисковом массиве.
Плюсы данного решения в следующем:
- Мы сокращаем размер основной базы, упрощая разворачивание и обновление тестовых баз. При этом для тестовых баз можно осуществлять доступ на чтение прикрепленных файлов.
- Мы как и в первом варианте разносим хранимые файлы и данные 1С по разным дисковым массивам, ускоряя работу системы в целом за счет распараллеливания.
- Мы снимаем с сервера приложений нагрузку по передаче хранимых файлов, т.к. соединения с базой будут идти от клиента на SQL сервер минуя сервер приложений 1С.
Эпилог
Сначала я хотел перетащить данные с помощью SQL, но решил тащить все же 1С, т.к. не хотелось, чтобы инфа была сжатой, да и в сам справочник писать информацию о размере файла и его UID было удобнее. Выгрузка базы прилагается, обработка по переносу данных - тоже. Все процедуры реализующие описанный выше функционалу по связи с внешней базой посредством ADO собраны в конце общего модуля РаботаСФайлами.
В самой конфе вам придется кое-что подправить ручками, эти строки отмечены комментариями вида "//РУЧНЫЕ ИЗМЕНЕНИЯ". Настроить нужно будет параметры подключения к внешней базе и строку подключения к базе 1С, которая будет нужна для защиты хранилища данных, на случай доступа к нему из тестовых баз.
На текущий момент база находится в рабочем режиме под полной нагрузкой: 200-250 пользователей онлайн, 2 обмена с БП, 1 обмен с УТ и 1 обмен с головной. Зависания 1С пропали, очередь на дисках приобрела нормальные показатели в 50% и до 90% в пике. При пиковых нагрузках зависаний 1с больше не наблюдается.
Добавление: 20/09/10 добавлено регламентное задание по очистке SQL базы от ссылок которых больше нет в справочнике ХранилищеДополнительнойИнформации.
Добавлено 03/07/17: данная публикация сделана в обычном приложении в неуправляемом интерфейсе. Есть развитие данного функционала для управляемого приложения и интерфейса Такси, которое реализует хранение файлов в базах MS SQL, Postgre SQL и MongoDB - //infostart.ru/public/624829/
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Внешние источники данных Разработчик Аналитик Пользователь 1С:Предприятие 8 1C:Бухгалтерия Узбекистан Беларусь Кыргызстан Молдова Россия Казахстан Платные (руб)
Готовое решение для автоматической выгрузки данных из 1С 8.3 в базу данных ClickHouse, PostgreSQL или Microsoft SQL для работы с данными 1С в BI-системах. «Экстрактор данных 1С в BI» работает со всеми типовыми и нестандартными конфигурациями 1С 8.3 и упрощает работу бизнес-аналитиков. Благодаря этому решению, специалистам не требуется быть программистами, чтобы легко получать данные из 1С в вашей BI-системе.
35000 руб.
15.11.2022 33803 53 49
Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Перенос данных 1C Разработчик 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)
Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактическим удержаниям, НДФЛ, вычетам, страховым взносам из базы Парус 10 учреждений (далее Парус) в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (далее 1С) и начать с ней работать с любого месяца года.
85400 руб.
05.10.2022 14562 17 8
Розничная торговля Внешние источники данных Разработчик Бухгалтер 1С:Предприятие 8 1С:Розница 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Розничная и сетевая торговля (FMCG) Бухгалтерский учет Управленческий учет Платные (руб)
Загрузка данных продаж и инкассаций из сервисов Kit Vending/Kit Shop в 1С. Реализовано в виде Расширения. Мониторинг состояний торговых автоматов.
12200 руб.
10.06.2019 34644 49 25
Зарплата Внешние источники данных Бюджетный учет Перенос данных 1C Системный администратор Разработчик 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)
Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактическим удержаниям, НДФЛ, вычетам, страховым взносам из базы Парус 8 учреждений (далее Парус) в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (далее 1С) и начать с ней работать с любого месяца года.
122000 руб.
19.08.2020 30619 28 3
Внешние источники данных Зарплата Бюджетный учет Разработчик Бухгалтер 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)
Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактическим удержаниям, НДФЛ, вычетам, страховым взносам из базы Парус 7.хх учреждений (далее Парус) в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (далее 1С) и начать с ней работать с любого месяца года.
85400 руб.
24.04.2017 57648 99 165
Универсальные функции 1С 8.3 1С:Документооборот Россия Платные (руб)
ДО+ — расширение конфигурации, в котором собран постоянно пополняемый набор из 33 востребованных доработок для 1С:Документооборот КОРП 3.0: согласование задач прямо из мессенджеров MAX и Telegram, отзыв согласования и исполнения, гибкие повторные круги, эскалация с точностью до минут, контроль исполнительской дисциплины, выгрузка вложений в ZIP и склейка PDF, реестр документов в Excel, проверка дублей контрагентов и регистрационных номеров. Каждая возможность активируется отдельным флажком в режиме предприятия — включается только то, что нужно конкретной организации. Список функций расширяется с каждым релизом — текущая версия 2.1.0. Режим AddOn: типовая конфигурация не модифицируется, обновления ДО ставятся штатно, дополнительные лицензии и внешние компоненты не требуются. Внедрение силами администратора — около часа.
30000 руб.
09.07.2026 1398 1 0
Производство готовой продукции (работ, услуг) Внешние источники данных 1С:Предприятие 8 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Лесное и деревообрабатывающее хозяйство Россия Управленческий учет Платные (руб)
Обработка предназначена для загрузки файлов, выгруженных из системы Базис-мебельщик, в справочник 1С "Спецификации" для последующих процессов учета и диспетчирования полуфабрикатов и изделий.
10370 руб.
24.06.2021 26845 66 55
Внешние источники данных Розничная торговля Разработчик Бухгалтер 1С:Предприятие 8 1С:Бухгалтерия 2.0 1С:Бухгалтерия 3.0 Здравоохранение, медицина, стоматология Розничная и сетевая торговля (FMCG) Россия Бухгалтерский учет Налоговый учет Платные (руб)
Внешняя обработка обмена данными между системами ЮНИКО и 1С:Бухгалтерия 3.0.
6100 руб.
01.11.2011 55494 129 81
надо было перенести часть данных в отдельную файловую группу на отдельные диски
(7) Помимо обращения к файлам, скорее всего есть еще работа с другими данными, с которыми данные пользователи работают. Это подсистема встроена во что-то более глобальное... Я так полагаю это либо БП либо УПП + сканы договоров с контрагентами, или что-то в этом духе? (0) поправь меня если ошибаюсь.
(0) Данное решение мне кажется имеет место быть.
Хотя можно было бы действительно разнести так:
1 сервер) база 1С + SQL хранится информация о файлах и GUID самих файлов
2 сервер) база 1С + SQL в которой содержался бы один справочник, в котором хранились бы сами файлы в ХранилищеЗначений без сжатия.
сервер 1. делал бы коннект при необходимости через внешнее соединение ко серверу 2. и возвращал бы нужный файл.
+ если используется 8.2, то можно использовать вызовы на стороне сервера, тогда вообще не важно что стоит у клиента, сервак 1 сам все будет доставать с сервака 2 и возвращать клиенту.
+ нет никаких заморочек с ADO, все штатно, надо посмотреть что за файлы открой базу 2 сервера, систематизируй, анализируй удаляй не нужные и смотри сколько влезет. При необходимости можно дополнить реквизитами типа Дата создания, организация, пользователь, контрагент и т.д.
+ на сервере 2 можно было бы использовать фоновые задания, которые чистили бы к примеру старье.
+ при записи в 1С можно было бы предусмотреть ситуацию, когда конфа переданную картинку на 2 серваке анализировала и обрабатывала соответсвующим образом сжимала ее программно, например все переводилось бы в jpeg к одиннаковым ширина и высота (если файл большой). При этом сервер 1. не страдал бы вообще.
- скорее всего работа через ADO непосредственно с SQL Server будет побыстрее, т.к. минует сервер 1С:Предприятия, но кто его знает ;) .
Думаю минусовать не за что... Человек предложил свой метод реализации, в чем то он хорош, в чем то плох...
2 Evg-Lylyk. На самом деле 2я база стала даже больше, т.к. не использовался механизм встроенного сжатия. Размер тут как раз не важен, важна скорость получения данных. А она в моем случае сильно страдала из-за большого объема файла базы данных.
насколько я понимаю из описания сканы хранились непосредственно в базе, а второй способ (сканы хранятся на дисках, а в 1С хранятся пути к ним) пробовали? Если, да то хотелось бы увидеть комментарий по этому поводу.
я так понимаю, что после установки новой базы Вам и схему обмена с головой пришлось менять. Или тащите старым способом, а потом в базу хранилище сканы отправляете?
почему для файлохранилища выбрана скулевская база, а не что-то из 1С? На мой взгляд, при необходимости 1Совскую базу легче корректировать.
1. У нас 150 тыс элементов, для файлового хранилища не самый лучший вариант на мой взгляд.
2. Схему обмена с головой поменяли незначительно, но тем не менее - да, поменяли.
3. При таких объемах данные нужно хранить в какой-либо СУБД, первоначально я посматривал в сторону документо-ориентированных СУБД, но понял что моей квалификации на их обслуживание явно не хватит. В итоге выбрал то, что знакомо больше и уже проверено.
4. А зачем? Идея была именно разнести обращение к данным 1С и прикрепленным файлам, вообще убрать их из 1С структуры, т.к. скорость их получения не критична, в отличие от тех же отчетов.
2 Evg-Lylyk Прирост дает, обратите внимание на первое сообщение Гилева, это по сути тоже самое, только подразумевает хранение файлов в той же базе 1С, но в другой файловой группе в рамках той же базы SQL. Мы с админом данный вариант обсуждали, но поскольку за 3 месяца мы прибавили 15 Гб файлов, то приняли решение убирать их вообще в отдельную базу. Проще и тестовые базы поднимать и обслуживание производить. Файлы же по сути не являются критичными для бизнеса данными, в отличие от документов.
что значит разнести!? если просто разнести по базам на одном компе одном диске это ничего не даст.
здесь одни сложности относительно изначального варианта
Описание запутывает, если бы его не было, тогда проще придумать объективные причины сделать так. А так как есть много вопросов почему пользователи обращаются так часто к этим файлам (200 юзверов 3 обращ./сек к файлам по 2 Мб итого 6 Мб/с для RAID ерунда).
Вполне возможно что описание запутывает, мой косяк - в ближайшее время переделаю.
(8) Это вообще самописная конфигурация, имеющая обмены с 1 УТ, 2 БП и 1 с самописной системой в голове.
2 сервер) база 1С + SQL в которой содержался бы один справочник, в котором хранились бы сами файлы в ХранилищеЗначений без сжатия.
Да, но тогда бы пришлось создавать COM не ADO, а 1С для доступа ко второй базе, ИМХО такое решение бы скоростью не отличалось точно. А так каждый пользователь напрямую запрашивает данные в SQL сервере, не трогая сервер приложений. Сегодня база будет под полной нагрузкой, опишу результат.
фразы вроде "Мы с админом данный вариант обсуждали" означают, что обоснованности нет, есть только самоуговаривания как лучше
реальных тестов - нет
сделали и заработали, т.е. пронесло
однако делать вывод о том, что стало лучше смешно, ведь задействовали новое железо, а вот это куда существенней
вцелом я допускаю такую реализацию, даже закроем глаза на пресловутое ЛС,
НО не надо это подавать как ПРАВИЛЬНОЕ решение
это Ваш частный случай
инетерсно что будет, когда кто-нибудь пойдет по вашему способу, но например оставит базу на том же сервере...
или еще где накосячит
минус не за то, что у вас работает, а что этому учите всех налево и направо
без обид
(10)
однако делать вывод о том, что стало лучше смешно, ведь задействовали новое железо, а вот это куда существенней
вцелом я допускаю такую реализацию, даже закроем глаза на пресловутое ЛС,
НО не надо это подавать как ПРАВИЛЬНОЕ решение
это Ваш частный случай
инетерсно что будет, когда кто-нибудь пойдет по вашему способу, но например оставит базу на том же сервере...
Стало лучше - да, задействовали новое железо - тоже да. Но тем не менее база находится на том же сервере только на другом дисковом массиве. Более того, в ближайшее время админы будут пересобирать рейдмассив и все временно переедет на один диск, будет интересно глянуть на результат этого кошмара.
По поводу ЛС - давайте все же не будем закрывать глаза и разберемся, что же тут не так. Есть база самописная 1С доступ к которой осуществляется целиком и полностью только через сервер приложений 1С и есть внешняя база SQL доступ к которой осуществляется по ADO. Если бы вторая база была бы 1Ская, я бы понял праведный гнев.
И на последок - не бывает ПРАВИЛЬНЫХ решений, есть лишь оптимальные с точки зрения доступных средств и финансов на определенный момент времени. И накосячивший программист способен накосячить не только через ADO, но и внутри 1С так, что потом несколько нормальных спецов потребуется.
объективных тестов не было!
еще раз, мне не нравиться ваше "учить жизни" 1сков нештатными средствами, как следует не оттестировав штатные
это мое личное мнение, а придумать почему так сложилось можно все что угодно, вплоть до религии,
некоторые на инфостарте вообще всюду предлгаюат юзать нетфреймворк, бог им в помощь
(15) Файловая система как раз не дает гарантии целостности. Про FAT говорить излишне, а NTFS, насколько мне известно, гарантирует целостность только MFT, а не содержимого файлов. Но с другой стороны, если необходимо получить эти изображения где-то в web, то такой вариант несколько проще.
Я имел ввиду ссылочную целостность.
Нам ничего другого не требовалось так как присутствовал:
1. Бекап изображений
2. Бумажный оригинал
Но за 10 лет использования не пришлось прибегать ни к одному из этих вариантов.
Больше про целостность ничего сказать не могу.
Ссылочная целостность как раз не гарантирована ни моим не вашим способом, удаляем файл или запись во внешней таблице и ссылочной целостности нет.
Появляются только накладные расходы на получение информации из базы SQL и сохранение на диск во временный файл. В чем плюс?
Если изображений не много, то можно хранить и в самой базе.
Если их довольно большое количество как по числу файлов вообще так и по размеру, то СУБД - оптимальное решение. Я читал о разных способах решения, в т.ч. о хранении в файловой системе и на ftp. В итоге люди ушли от этого, т.к. поддерживать целостность данного массива довольно сложно и скорость доступа этого решения на больших объемах была крайне мала. Яндекс вам в помощь.
А вариантов хранения в СУБД может быть несколько, самый простой случай создать файловую группу, перенести туда вашу таблицу и вынести эту таблицу на другой физический дисковый массив.
- накладные расходы на доступ к базе SQL
- накладные расходы на сохранение файлов на диск перед любыми действиями с ними
Хранение сразу на диске не вызывает никаких проблем с контролем целостности по сравнению с внешней базой SQL. Производительность файловой системы достаточна при использовании отдельных папок и ограничения количества файлов в одной папке. Вот я и хотел уточнить о наличии дополнительных плюсов и минусов о которых мне неизвестно.
(14) Штатные методы хранения изображений в базе мне не нравятся в связи со сложностями в резервном копировании и последующим восстановлении из резервных копий.
Какие вижу плюсы:
1. Скорость восстановления "рабочей" базы не обремененной хранилищем значительно выше.
2. Обращение к данным в отдельной базе возможно из нескольких конфигураций, следовательно отпадает необходимость в дублировании.
Минусы:
Скорость (получения данных из отдельного хранилища), скорее всего будет ниже.
to (24) А увеличение это не сжатые "картинки" я так понимаю...
Штатные механизмы и возможности -- это конечно хорошо, но иногда временные и бюджетные рамки не позволяют сделать все "идеально".
В конкретном данном случае этот вариант -- хороший выход из положения. И мотивация автора в данном случае полностью понятна.
.
не понял только одного? в чем вкусности решения?
(29) Через XML. Насколько я помню, там используется XDTO пакет. Точнее не скажу, не я писал.
Для поддержания ссылочной целостности у меня крутится регламентное задание на проверку и очистку битых.
если процы мощные (там где сжимется... если это не управляемое приложение - то на клиенте... а там ваще Г может быть)
можно сжимать (deflate).. при записи задержка.. при чтении иногда быстрее
+ но надо анализировать сжимать не сжимать ....
Сделал табличку
CREATE TABLE "FileTable"
(
"FileID" character(36) NOT NULL,
"Object" bytea
)
при попытке обратиться через Recordset к полю Object вываливаеться с ошибкой
Произошла исключительная ситуация (Provider): Недостаточно памяти для завершения операции.Может есть какие мысли?
- это откуда такое мнение???
Запись файлов в хранилище возможна только на рабочей базе
Не удалось поместить файл в хранилище через ADO соединение
Насколько я понял, что надо указать путь к ИБ. Вот только я думаю, как его указать, скорее всего мой вариант не верный
Функция ПоместитьФайлВХранилище(СоединениеАДО, УникальныйИдентификаторФайла, ПолноеИмяФайла) Экспорт
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), """", "") <> "File=""C:\\InfoBase""; Usr =""Админ"";") Тогда //РУЧНЫЕ ИЗМЕНЕНИЯ
#Если Клиент Тогда
Сообщить("Запись файлов в хранилище возможна только на рабочей базе", СтатусСообщения.Важное);
#КонецЕсли
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), "File=""C:\InfoBase""; Usr =""Админ", "") <> "СтрокаСоединенияСИнформационнойБазой") Тогда //РУЧНЫЕ ИЗМЕНЕНИЯ
после чего выдает ошибку
"Запись файлов в хранилище возможна только на рабочей базе"
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), """", "") <>
"File=""C:\\InfoBase""; Usr =""Админ"";") Тогдаисследуйте левый операнд в условии
СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), """", "")поместите в правую часть.
Суть условия - исключить выполнение функции в тестовой базе.
//помещает файл в хранилище
Функция ПоместитьФайлВХранилище(СоединениеАДО, УникальныйИдентификаторФайла, ПолноеИмяФайла) Экспорт
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), """","") <> "СтрокаСоединенияСИнформационнойБазой") Тогда //РУЧНЫЕ ИЗМЕНЕНИЯ
#Если Клиент Тогда
Сообщить("Запись файлов в хранилище возможна только на рабочей базе", СтатусСообщения.Важное);
#КонецЕсли
//Возврат;
КонецЕсли;
Попытка
//Дабы не мудртвовать лукаво, просто удалим строку с определенным ИД
КомандаSQL = Новый COMObject("ADODB.Command");
КомандаSQL.ActiveConnection = СоединениеАДО;
КомандаSQL.CommandText = "DELETE FROM FileTable WHERE (FileID='" + УникальныйИдентификаторФайла + "')";
КомандаSQL.CommandType = 1;
КомандаSQL.Execute();
//создаем набор записей АДО
НаборЗаписей = Новый COMОбъект("ADODB.Recordset");
НаборЗаписей.CursorLocation = 2;
НаборЗаписей.Open("FileTable", СоединениеАДО, 0, 4, 2);
НаборЗаписей.AddNew();
НаборЗаписей.Fields("FileID").Value = УникальныйИдентификаторФайла;
//создаем АДО поток для чтения файла
Поток = Новый COMОбъект("ADODB.Stream");
Поток.Type = 1;
Поток.Open();
Поток.LoadFromFile(ПолноеИмяФайла);
НаборЗаписей.Fields("Object").Value = Поток.Read();
//обновляем набор записей и закрываем его
НаборЗаписей.UpdateBatch();
НаборЗаписей.Close();
Возврат Истина;
Исключение
#Если Клиент Тогда
Сообщить("Не удалось поместить файл в хранилище через ADO соединение", СтатусСообщения.Важное);
#КонецЕсли
Возврат Ложь;
КонецПопытки;
КонецФункции //ПоместитьФайлВХранилище
Показать
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), """","") <> "СтрокаСоединенияСИнформационнойБазой") Тогда //РУЧНЫЕ ИЗМЕНЕНИЯ
#Если Клиент Тогда
Сообщить("Запись файлов в хранилище возможна только на рабочей базе", СтатусСообщения.Важное);
#КонецЕсли
//Возврат;
КонецЕсли;
Попробуйте этот кусок закомментировать
С изображениями как такого проблем нету. Все работает как по маслу. А вот при работе с файлами сохраняет без проблем ну вот при открытие выдает ошибку
{ОбщийМодуль.РаботаСФайлами.Модуль(850)}: Поле объекта не обнаружено (ИДФайла)
Хранилище = Новый ХранилищеЗначения(ПолучитьДанныеИзХранилища(СоединениеАДО, ОбъектФайла.ИДФайла, СокрЛП(ОбъектФайла.ИмяФайла)));
а в чем тут проблема?
Хранить файловую помойку в загруженной базе мы посчитали не серьезным и вынесли в отдельную базу SQL.
У нас картинки и сканы документов хранятся в отдельной SQL базе, доступ на чтение через внешний источник данных, запись как в примере . Все функции работы с внешней базой на сервере 1с.
Плюсы
Скорость работы базы выше, при активной работе с документами нет нагрузки на основную базу.
Резервное копирование основной базы быстрее, размер копий меньше со всеми вытекающими.
База картинок в нашем случае общая на несколько баз, каталог на сайте тоже с нее читает.
Минусы
Размер базы 3x от размера картинок( зато нет файловых операций)
Администрировать приходиться на одну базу больше.
В случае отказа базы картинок , в основной базе их нет, но база продолжает работать.
Необходима обработка для переноса имеющихся картинок и доработка конфигураций.
Здесь есть пример отталкивался от него, полгода работает стабильно.
А данная статья автора в чем-то похожа на другую мою статью, там уже все хранится не в Base64, а в бинарном виде. Работало отлично.
Процедура ОбработкаВыбора(ЗначениеВыбора, Источник)
Если ТипЗнч(ЗначениеВыбора) = Тип("Строка") Тогда
Если ЗначениеВыбора = "ИзмененСписокСправочникаХранилищеДопИнформации" Тогда
СписокКнопокФайлов = Новый СписокЗначений;
СписокКнопокФайлов.Добавить(ЭлементыФормы.ДействияФормы.Кнопки.Файлы);
РаботаСФайлами.ПолучитьКартинкуКнопкиОткрытияФайлов(Ссылка, СписокКнопокФайлов);
КонецЕсли;
Иначе
;
КонецЕсли;
КонецПроцедуры
Показатьне должна быть ОбработкаОповещения ? Ведь везде оповещение а не выбор
Оповестить("ОбновитьФорму", Новый Структура("ИмяЭлемента","ИзмененСписокСправочникаХранилищеДопИнформации"),мОбъектОтбора);
(68) если это odbc, то можете бросить в меня камнем. не вводите людей в заблуждение
КомандаSQL = Новый COMObject("ADODB.Command");
КомандаSQL.ActiveConnection = СоединениеАДО;
КомандаSQL.CommandType = 1;
Пока (Выборка.Следующий()) Цикл
КомандаSQL.CommandText = "DELETE FR OM FileTable WH ERE (FileID='" + Выборка.ИДSQL + "')";
КомандаSQL.Execute();
КонецЦикла;
Конкретно интересует этот момент:
Поток = Новый COMОбъект("ADODB.Stream");
Поток.Type = 1;
Поток.Open();
Поток.LoadFromFile(ПолноеИмяФайла);
НаборЗаписей.Fields("Object").Value = Поток.Read();
В целом все работает корректно и далее происходит помещение файлов в таблицу SQL для всех файлов всех форматов отличных от текстовых (word, txt). А вот с word-ом проблемы. Команда чтения из потока для него ничего не дает. В результате в таблицу SQL вместо файла записывается значение "NULL". Можете объяснить как работать с данными типами файлов?
Дело в том, что файл вордовский я создал для теста, но ничего в него не написал. Тем самым размер файла получился 0, и соответственно в SQL записывался NULL, а далее уже при чтении валилась ошибка. Если добавлять не пустой файл, то все хорошо.
Добавил проверку при обработке на нулевой размер файла, теперь все норм.
"Не удалось загрузить файл из хранилища через ADO соединение".
После того как не удалось приложить большой файл, не удаётся приложить и маленький, пока не переоткроешь документ.
Во второй базе подобных проблем не возникает.
Честно говоря не пойму куда "копать"))).
Поток.Open();
Поток.Type = 1;
Поток.LoadFromFile(ПолноеИмяФайла);
Поток.Position = 0;
НаборЗаписей.Fields("Object").Value = Поток.Read();
НаборЗаписей.UpdateBatch()
После UpdateBatch ошибка.... Пробовал файлы различных форматов, проверял базу на ошибки и т.п. Такое чувство, что где-то в свойствах базы SQL необходимо увеличить размер максимально принимаемой информации. Но к сожалению ничего подобного не нашёл.
Autogrowth установлено 200МБ для мдф, и 10% для лдф.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 74821
Создание 29.08.10 13:31
Обновление 03.07.17 00:05
Просмотры 54699
Загрузки 658
Рейтинг
78
Комментарии 85
Код открыт Да
Рубрики Внешние источники данных Универсальные функции
Кому Разработчик
Тип файла Конфигурация (md, cf)
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Windows
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
