gifts2017

Пример реализации хранения файлов и изображений во внешней СУБД MS SQL

Опубликовал Алексей Соловьев (Silenser) в раздел Обмен - Обмен с другими системами

Данная конфигурация создана на основе стандартного механизма 1С - ХранилищеДополнительнойИнформации, с той лишь разницей, что бинарные данные хранятся не в самом элементе справочника, а во внешней базе на MS SQL сервере.

Преамбула

До сего момента в нашей организации в самописной конфе использовался стандартный механизм из типовой торговли - ХранилищеДополнительнойИнформации, но когда объем базы достиг 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 базы от ссылок которых больше нет в справочнике ХранилищеДополнительнойИнформации.

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Конфигурация с примером реализации описанного функционала
.dt 86,37Kb
29.08.14
437
.dt 86,37Kb 437 Скачать
Обработка по переносу данных
.epf 6,26Kb
29.08.14
144
.epf 6,26Kb 144 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. gilv (Gilev.Vyacheslav) 29.08.10 16:29
минус за введение в заблуждение 1Сков
надо было перенести часть данных в отдельную файловую группу на отдельные диски
Трактор; +1 Ответить 1
2. Евгений Люлюк (Evg-Lylyk) 29.08.10 19:30
Не понял
зачем это нужно :?:
"Размер базы 1с уменьшился в 4 раза" разве не появилась база SQL размером 3/4
Появилось лишнее звено
3. Алексей Соловьев (Silenser) 29.08.10 19:32
2 Гилев. Мне показалось лишним включать в передачу этих данных сервер приложений, да и тестовая база будет разворачиваться гораздо быстрее, т.к. восстановить нужно будет только данные, которых существенно меньше.
2 Evg-Lylyk. На самом деле 2я база стала даже больше, т.к. не использовался механизм встроенного сжатия. Размер тут как раз не важен, важна скорость получения данных. А она в моем случае сильно страдала из-за большого объема файла базы данных.
Olenevod; DMSDeveloper; +2 Ответить 1
4. Сергей Троицкий (tsd) 29.08.10 19:56
В ходе анализа выяснилось, что при 200 пользователях онлайн и таких объемах базы и хранимых там файлов дисковая подсистема вполне себе неплохого хьюлитовского блейда просто умирала: очередь диска была не меньше 70%, а во время любого регламентного задания, связанного с доступом к сканам не опускалась меньше 95-100%.

насколько я понимаю из описания сканы хранились непосредственно в базе, а второй способ (сканы хранятся на дисках, а в 1С хранятся пути к ним) пробовали? Если, да то хотелось бы увидеть комментарий по этому поводу.

При обменных процессах, когда шло обращение к хранимым данным наблюдалось дикое торможение, т.к. из головной организации нам шла куча сканов по 2-3 Мб. Видимо такие большие объемы в купе со встроенным сжатием наводили систему на размышление об отдыхе.


я так понимаю, что после установки новой базы Вам и схему обмена с головой пришлось менять. Или тащите старым способом, а потом в базу хранилище сканы отправляете?


В итоге, было принято решение разнести хранимые файлы и данные. На MS SQL была создана база состоящая из 1 таблицы:

почему для файлохранилища выбрана скулевская база, а не что-то из 1С? На мой взгляд, при необходимости 1Совскую базу легче корректировать.
5. Евгений Люлюк (Evg-Lylyk) 29.08.10 19:56
(3) Непонятно какой прирост это дает в каких случаях (и дает ли вообще)
При помещении в реквизит хранилище можно не сжимать.
Мне кажется задачу можно и нужно было решать в рамках 1С8
6. Алексей Соловьев (Silenser) 29.08.10 21:18
2 tsd
1. У нас 150 тыс элементов, для файлового хранилища не самый лучший вариант на мой взгляд.
2. Схему обмена с головой поменяли незначительно, но тем не менее - да, поменяли.
3. При таких объемах данные нужно хранить в какой-либо СУБД, первоначально я посматривал в сторону документо-ориентированных СУБД, но понял что моей квалификации на их обслуживание явно не хватит. В итоге выбрал то, что знакомо больше и уже проверено.
4. А зачем? Идея была именно разнести обращение к данным 1С и прикрепленным файлам, вообще убрать их из 1С структуры, т.к. скорость их получения не критична, в отличие от тех же отчетов.
2 Evg-Lylyk Прирост дает, обратите внимание на первое сообщение Гилева, это по сути тоже самое, только подразумевает хранение файлов в той же базе 1С, но в другой файловой группе в рамках той же базы SQL. Мы с админом данный вариант обсуждали, но поскольку за 3 месяца мы прибавили 15 Гб файлов, то приняли решение убирать их вообще в отдельную базу. Проще и тестовые базы поднимать и обслуживание производить. Файлы же по сути не являются критичными для бизнеса данными, в отличие от документов.
7. Евгений Люлюк (Evg-Lylyk) 29.08.10 22:30
(6) Это все на одном сервере? если да, то можно база на 1С и работа через COM.
В итоге, было принято решение разнести хранимые файлы и данные

что значит разнести!? если просто разнести по базам на одном компе одном диске это ничего не даст.
Мы с админом данный вариант обсуждали, но поскольку за 3 месяца мы прибавили 15 Гб файлов, то приняли решение убирать их вообще в отдельную базу. Проще и тестовые базы поднимать и обслуживание производить.

здесь одни сложности относительно изначального варианта

Описание запутывает, если бы его не было, тогда проще придумать объективные причины сделать так. А так как есть много вопросов почему пользователи обращаются так часто к этим файлам (200 юзверов 3 обращ./сек к файлам по 2 Мб итого 6 Мб/с для RAID ерунда).
8. Виталий Барилко (Diversus) 29.08.10 23:48
(1) При такой реализации с самой базой будет трудно работать программеру, ну ка представь сколько нужно разворачивать тестовую базу?
(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С:Предприятия, но кто его знает ;) .

Думаю минусовать не за что... Человек предложил свой метод реализации, в чем то он хорош, в чем то плох...

9. Алексей Соловьев (Silenser) 30.08.10 08:49
(7)
что значит разнести!? если просто разнести по базам на одном компе одном диске это ничего не даст.
Базы разнесены на разные дисковые массивы, и таки выигрыш производительности все же достигнут.

Вполне возможно что описание запутывает, мой косяк - в ближайшее время переделаю.
(8) Это вообще самописная конфигурация, имеющая обмены с 1 УТ, 2 БП и 1 с самописной системой в голове.
1 сервер) база 1С + SQL хранится информация о файлах и GUID самих файлов
2 сервер) база 1С + SQL в которой содержался бы один справочник, в котором хранились бы сами файлы в ХранилищеЗначений без сжатия.

Да, но тогда бы пришлось создавать COM не ADO, а 1С для доступа ко второй базе, ИМХО такое решение бы скоростью не отличалось точно. А так каждый пользователь напрямую запрашивает данные в SQL сервере, не трогая сервер приложений. Сегодня база будет под полной нагрузкой, опишу результат.
10. gilv (Gilev.Vyacheslav) 30.08.10 10:32
подвожу итог
фразы вроде "Мы с админом данный вариант обсуждали" означают, что обоснованности нет, есть только самоуговаривания как лучше
реальных тестов - нет

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

вцелом я допускаю такую реализацию, даже закроем глаза на пресловутое ЛС,
НО не надо это подавать как ПРАВИЛЬНОЕ решение

это Ваш частный случай

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

или еще где накосячит

минус не за то, что у вас работает, а что этому учите всех налево и направо
без обид
ily.fomin; Maximysis; GentleMax; +3 Ответить 1
11. Gamm (Gamm) 30.08.10 11:19
А объясните мне насколько выгоднее хранение изображений в SQL чем просто хранить отдельной папке?
Появляются только накладные расходы на получение информации из базы SQL и сохранение на диск во временный файл. В чем плюс?
12. Алексей Соловьев (Silenser) 30.08.10 11:23
Описание обновил, надеюсь так будет чуть понятнее, если что - поправите плиз.
(10)
реальных тестов - нет
Я и админ ориентировались на счетчики производительности системы, к сожалению, скриншотов нет, т.к. задача была не теоретической, и решение принимать нужно было быстро да и разворачивать тестовую базу с новым решением попросту негде.

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

вцелом я допускаю такую реализацию, даже закроем глаза на пресловутое ЛС,
НО не надо это подавать как ПРАВИЛЬНОЕ решение

это Ваш частный случай

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

Стало лучше - да, задействовали новое железо - тоже да. Но тем не менее база находится на том же сервере только на другом дисковом массиве. Более того, в ближайшее время админы будут пересобирать рейдмассив и все временно переедет на один диск, будет интересно глянуть на результат этого кошмара.
По поводу ЛС - давайте все же не будем закрывать глаза и разберемся, что же тут не так. Есть база самописная 1С доступ к которой осуществляется целиком и полностью только через сервер приложений 1С и есть внешняя база SQL доступ к которой осуществляется по ADO. Если бы вторая база была бы 1Ская, я бы понял праведный гнев.
И на последок - не бывает ПРАВИЛЬНЫХ решений, есть лишь оптимальные с точки зрения доступных средств и финансов на определенный момент времени. И накосячивший программист способен накосячить не только через ADO, но и внутри 1С так, что потом несколько нормальных спецов потребуется.
13. Алексей Соловьев (Silenser) 30.08.10 11:37
(11) Тут только ИМХО, если что более опытные меня поправят. Все целиком и полностью зависит от масштаба бедствия: сколько пользователей, каков размер базы и таблицы хранилища файлов, сколько элементов в данной таблице.
Если изображений не много, то можно хранить и в самой базе.
Если их довольно большое количество как по числу файлов вообще так и по размеру, то СУБД - оптимальное решение. Я читал о разных способах решения, в т.ч. о хранении в файловой системе и на ftp. В итоге люди ушли от этого, т.к. поддерживать целостность данного массива довольно сложно и скорость доступа этого решения на больших объемах была крайне мала. Яндекс вам в помощь.
А вариантов хранения в СУБД может быть несколько, самый простой случай создать файловую группу, перенести туда вашу таблицу и вынести эту таблицу на другой физический дисковый массив.
14. gilv (Gilev.Vyacheslav) 30.08.10 11:55
(12) нет времени, негде тестировать - это все частности
объективных тестов не было!

еще раз, мне не нравиться ваше "учить жизни" 1сков нештатными средствами, как следует не оттестировав штатные

это мое личное мнение, а придумать почему так сложилось можно все что угодно, вплоть до религии,
некоторые на инфостарте вообще всюду предлгаюат юзать нетфреймворк, бог им в помощь
15. Gamm (Gamm) 30.08.10 12:38
(13) Знаком со всеми перечисленными вариантами хранения, просто непонятны плюсы от использования SQL. Моё мнение что от использования SQL получаем только дополнительные минусы о которых я уже писал:
- накладные расходы на доступ к базе SQL
- накладные расходы на сохранение файлов на диск перед любыми действиями с ними

Хранение сразу на диске не вызывает никаких проблем с контролем целостности по сравнению с внешней базой SQL. Производительность файловой системы достаточна при использовании отдельных папок и ограничения количества файлов в одной папке. Вот я и хотел уточнить о наличии дополнительных плюсов и минусов о которых мне неизвестно.

(14) Штатные методы хранения изображений в базе мне не нравятся в связи со сложностями в резервном копировании и последующим восстановлении из резервных копий.
Gilev.Vyacheslav; +1 Ответить 1
16. Алексей Соловьев (Silenser) 30.08.10 14:09
(14) Есть проблема. Есть вариант решения проблемы. Причины по которым штатные средства не подходят описаны. Причинно следственная связь прослеживается. Включаться же в спор между вами и ярлыком который на меня был повешен считаю излишним.

(15) Файловая система как раз не дает гарантии целостности. Про FAT говорить излишне, а NTFS, насколько мне известно, гарантирует целостность только MFT, а не содержимого файлов. Но с другой стороны, если необходимо получить эти изображения где-то в web, то такой вариант несколько проще.
17. Gamm (Gamm) 30.08.10 15:04
(16) Какой контроль целостности имеется в виду?
Я имел ввиду ссылочную целостность.
Нам ничего другого не требовалось так как присутствовал:
1. Бекап изображений
2. Бумажный оригинал

Но за 10 лет использования не пришлось прибегать ни к одному из этих вариантов.
Больше про целостность ничего сказать не могу.
18. Алексей Соловьев (Silenser) 30.08.10 15:27
(17) Имелась ввиду целостность данных, когда происходит сбой во время записи данных.
Ссылочная целостность как раз не гарантирована ни моим не вашим способом, удаляем файл или запись во внешней таблице и ссылочной целостности нет.
19. Сергей (totskysergey) 31.08.10 14:47
Думаю что такой подход имеет правона существование.
Какие вижу плюсы:
1. Скорость восстановления "рабочей" базы не обремененной хранилищем значительно выше.
2. Обращение к данным в отдельной базе возможно из нескольких конфигураций, следовательно отпадает необходимость в дублировании.
Минусы:
Скорость (получения данных из отдельного хранилища), скорее всего будет ниже.
20. Вадим Никонов (V.Nikonov) 31.08.10 19:17
А как насчёт борьбы с "потеряными" записями? Они будут постепенно образовываться в базе (хранилище) с отсутствующими ссылками на них...
21. Алексей Соловьев (Silenser) 01.09.10 17:01
(19) Да по идее не должно оно быть ниже, 1 звено из цепи уходит. Поднял старую базу в качестве тестовой и проверил, результаты в аттаче.
Прикрепленные файлы:
22. Алексей Соловьев (Silenser) 01.09.10 17:02
(20) допишу чуть позже, работы многовато :o
23. Доржи Балбаров (Angeros) 02.09.10 08:27
Ну и каков стал размер базы картинок хранящихся в sql А не в 1с*? хочется узнать разницу.
24. Алексей Соловьев (Silenser) 02.09.10 09:26
25. Сергей (totskysergey) 02.09.10 10:08
to (20) Теоретически они могут быть и в единой базе. Так что это тема "цены вопроса"? Для каждого в конкретном случае она своя.
to (24) А увеличение это не сжатые "картинки" я так понимаю...
26. Dmitry Afanasyev (afanasko) 02.09.10 15:06
Вполне достойное решение, имеющее право на жизнь.
Штатные механизмы и возможности -- это конечно хорошо, но иногда временные и бюджетные рамки не позволяют сделать все "идеально".
В конкретном данном случае этот вариант -- хороший выход из положения. И мотивация автора в данном случае полностью понятна.
27. Сергей (Che) Коцюра (CheBurator) 03.09.10 01:44
ндя... радует что 8осьмерошнику идея отвязать сопросодительную "незначимую" инфу вынести з апределы базы пришла в голову только сейчас, в то время как 7-ки это делали давно... ;-)
.
не понял только одного? в чем вкусности решения?
28. Rabajaba Caspersky (Rabajaba) 06.09.10 12:47
Тоже способ хранения. Однако по своему опыту делаю всё на внешних файлах - BLOB как-то не по душе ... А в рамках 8.2 с файлами работать стало проще, не надо теперь шару открывать на сервере.
Для поддержания ссылочной целостности у меня крутится регламентное задание на проверку и очистку битых.
29. Анатолий (natan) 07.09.10 09:02
Можно подробнее про обмен с головой? Каким образом передаются файлы?
30. Алексей Соловьев (Silenser) 20.09.10 17:23
(27) Справедливости ради, заметим, что помещать бинарные данные в 1С базу версии 7.7 нельзя, так что лирическое отступление странное. Вкусности решения, описаны выше: более быстрый бекап/восстановление тестовых баз, меньше нагрузка на RAID с базой.
(29) Через XML. Насколько я помню, там используется XDTO пакет. Точнее не скажу, не я писал.
31. Сергей (Che) Коцюра (CheBurator) 20.09.10 18:26
Справедливости ради, заметим, что помещать бинарные данные в 1С базу версии 7.7 нельзя,

- это откуда такое мнение???
32. Алексей Соловьев (Silenser) 20.09.10 23:43
(31)Если не сложно, напомните мне, насколько я помню, кроме как финта с ушами в виде сохранения объекта в виде строки с внутренним представлением встроенной процедурой, другого способа нет. То есть напрямую загнать бинарные данные в реквизит не получится, или я не прав?
33. Слава (DeepDiver) 28.10.10 14:04
Тоже интересный способ...
34. lylik 23.03.11 15:00
Коллеги, в данном примере формат сохранения в SQL базу идет 0xFFD8FF -- это живой JPEG.
А, кто знает формат хранения в SQL сервере изображения записываемого самой 1С ?
35. Виталий Журавлев (dmd) 11.10.11 19:35
Прекрасный пример, приспособил под собственные нужды. Спасибо автору.
36. Михаил Швец (MiCe) 23.01.12 07:30
(28)при больших нагрузках sql ado stream быстрее чем file acces ИМХО....
если процы мощные (там где сжимется... если это не управляемое приложение - то на клиенте... а там ваще Г может быть)
можно сжимать (deflate).. при записи задержка.. при чтении иногда быстрее
+ но надо анализировать сжимать не сжимать ....
37. Михаил Швец (MiCe) 23.01.12 07:31
38. Alex Ivanov (Ku2sha) 26.02.12 01:26
Автору - спасибо! Очень помогло, в нужное время в нужном месте. =))
39. KV1s (KroVladS) 07.08.12 08:42
Пытаюсь адаптировать для PostgreSQL.
Сделал табличку
CREATE TABLE "FileTable"
(
  "FileID" character(36) NOT NULL,
  "Object" bytea
)
...Показать Скрыть

при попытке обратиться через Recordset к полю Object вываливаеться с ошибкой
Произошла исключительная ситуация (Provider): Недостаточно памяти для завершения операции.

Может есть какие мысли?
40. Алексей Соловьев (Silenser) 11.08.12 09:34
(39) KV1s, К сожалению, с данной СУБД ни разу не сталкивался. Попробуйте задать вопрос на сайте соответствующего сообщества, наверняка есть подобное как sql.ru
41. KV1s (KroVladS) 14.08.12 17:53
(40) Silenser,
Вроде разобрался, правда через Ж
Использовал ADODB.Command с параметрами для добавления через AppendChunk и драйвер ODBC.
Ветка на соответствующем форуме тыц.
42. Алексей Соловьев (Silenser) 15.08.12 09:02
(41) KV1s, Почему же через Ж, ничего кривого в той ветке я не увидел.
43. Алексей К (Shum23str) 09.01.13 09:57
А для управляемых форм подойдет?
44. Алексей Соловьев (Silenser) 09.01.13 11:01
(43) Shum23str, Сама конфа работать, конечно, не будет, а внутренняя часть, отвечающая за подключение к SQL базе и получение файла - да.
45. Ulugbek Yuldashev (dynamite) 12.01.13 10:51
Добрый день, при попытке закрепит файл, ругается и выдает ошибку

Запись файлов в хранилище возможна только на рабочей базе
Не удалось поместить файл в хранилище через ADO соединение

Насколько я понял, что надо указать путь к ИБ. Вот только я думаю, как его указать, скорее всего мой вариант не верный

Функция ПоместитьФайлВХранилище(СоединениеАДО, УникальныйИдентификаторФайла, ПолноеИмяФайла) Экспорт
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), """", "") <> "File=""C:\\InfoBase""; Usr =""Админ"";") Тогда //РУЧНЫЕ ИЗМЕНЕНИЯ
#Если Клиент Тогда
Сообщить("Запись файлов в хранилище возможна только на рабочей базе", СтатусСообщения.Важное);
#КонецЕсли
46. Алексей Соловьев (Silenser) 13.01.13 01:31
(45) dynamite, Добрый день! На первый взгляд ошибка в указании строки соединения. Введите в табло СтрокаСоединенияИнформационнойБазы() и проверьте, не забудьте про функцию НРег в условии.
47. Ulugbek Yuldashev (dynamite) 13.01.13 20:09
(46) Сможете описать в примере... если честно я не так силен в программирование...

Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), "File=""C:\InfoBase""; Usr =""Админ", "") <> "СтрокаСоединенияСИнформационнойБазой") Тогда //РУЧНЫЕ ИЗМЕНЕНИЯ

после чего выдает ошибку

"Запись файлов в хранилище возможна только на рабочей базе"
48. Алексей Соловьев (Silenser) 13.01.13 20:44
(47) dynamite, Если еще проще, то запустите отладчик, установите точку останова на условии
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), """", "") <>
 "File=""C:\\InfoBase""; Usr =""Админ"";") Тогда

исследуйте левый операнд в условии
СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), """", "")

поместите в правую часть.
Суть условия - исключить выполнение функции в тестовой базе.
49. Ulugbek Yuldashev (dynamite) 13.01.13 22:23
(48)Silenser, я так понял то что я делаю не правильно да?

Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), "File=""C:\InfoBase""; Usr =""Админ", "") <> "СтрокаСоединенияСИнформационнойБазой") Тогда
50. TMV 13.01.13 22:35
51. Ulugbek Yuldashev (dynamite) 13.01.13 22:38
(50) TMV, а мне зачам издиватса, я же ясно выразилса что я не могу сделат... если можете могли бы дать просто вариант как написать...

Просто мне очень надо этот функцыанал
52. TMV 13.01.13 22:44
(51) dynamite, кидайте всю процедуру - глянем
53. Ulugbek Yuldashev (dynamite) 13.01.13 22:48
//помещает файл в хранилище
Функция ПоместитьФайлВХранилище(СоединениеАДО, УникальныйИдентификаторФайла, ПолноеИмяФайла) Экспорт
	Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), """","") <> "СтрокаСоединенияСИнформационнойБазой") Тогда //РУЧНЫЕ ИЗМЕНЕНИЯ
		#Если Клиент Тогда
			Сообщить("Запись файлов в хранилище возможна только на рабочей базе", СтатусСообщения.Важное); 
		#КонецЕсли
		//Возврат;
	КонецЕсли;
	Попытка
		//Дабы не мудртвовать лукаво, просто удалим строку с определенным ИД
		Команда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 соединение", СтатусСообщения.Важное); 
		#КонецЕсли
		Возврат Ложь;
	КонецПопытки;
КонецФункции //ПоместитьФайлВХранилище
...Показать Скрыть
54. TMV 13.01.13 22:54
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), """","") <> "СтрокаСоединенияСИнформационнойБазой") Тогда //РУЧНЫЕ ИЗМЕНЕНИЯ
  #Если Клиент Тогда
  Сообщить("Запись файлов в хранилище возможна только на рабочей базе", СтатусСообщения.Важное);
  #КонецЕсли
  //Возврат;
КонецЕсли;
...Показать Скрыть

Попробуйте этот кусок закомментировать
55. Вадим Вадим (reeds) 14.01.13 01:31
Была похожая проблема, решил файлы хранить просто на сервере в скрытой папке, а в 1С записывалась ссылка (путь) к данному файлу, естественно имя файла менялось программно чтобы можно было хранить файлы с одинаковым именем.
56. Ulugbek Yuldashev (dynamite) 14.01.13 11:20
Если его закомментит то проблема решает сразу... пробовал
Только вот при этом все ли нормально работает или нет, как определит?
И вообще это кусок кода за что отвечает?
57. Ulugbek Yuldashev (dynamite) 14.01.13 11:47
(54) TMV, Я посмотрел... там появляется проблема №1 что нельзя указать название файла, так же мы не можем изменят или назначать имена
58. Алексей Соловьев (Silenser) 14.01.13 14:02
(56) dynamite, Вы читаете то, что вам пишут? См. 48 коммент.
59. Ulugbek Yuldashev (dynamite) 14.01.13 14:51
(58) Silenser, Да да уже разобрался с этим, появился другой вопрос.

С изображениями как такого проблем нету. Все работает как по маслу. А вот при работе с файлами сохраняет без проблем ну вот при открытие выдает ошибку

{ОбщийМодуль.РаботаСФайлами.Модуль(850)}: Поле объекта не обнаружено (ИДФайла)
			Хранилище = Новый ХранилищеЗначения(ПолучитьДанныеИзХранилища(СоединениеАДО, ОбъектФайла.ИДФайла, СокрЛП(ОбъектФайла.ИмяФайла)));


а в чем тут проблема?
60. Алексей Соловьев (Silenser) 14.01.13 16:31
(59) dynamite, Скорее всего в списке нет указанного поля, нужно его добавить через настройки списка в режиме предприятия.
61. miroha Мирошниченко (miroha) 30.10.13 23:37
Изначально файловую помойку изображений хранили на файловом сервере, сплошные проблемы прав и доступа - каменный век для большого количества файлов.
Хранить файловую помойку в загруженной базе мы посчитали не серьезным и вынесли в отдельную базу SQL.

У нас картинки и сканы документов хранятся в отдельной SQL базе, доступ на чтение через внешний источник данных, запись как в примере http://infostart.ru/public/67205/ . Все функции работы с внешней базой на сервере 1с.

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

Минусы
Размер базы 3x от размера картинок( зато нет файловых операций)
Администрировать приходиться на одну базу больше.
В случае отказа базы картинок , в основной базе их нет, но база продолжает работать.
Необходима обработка для переноса имеющихся картинок и доработка конфигураций.

Здесь есть пример отталкивался от него, полгода работает стабильно.
62. Сергей Сергеев (SERJ_1CC) 09.12.14 11:43
(55) reeds, А по подробней не мог бы написать о таком спосабе хранения файлов, появились ли в дальнейшем проблемы и как именно реализовывал, а то все пишет только о внешних СУБД.
P.C. можно и в личку
63. Ivon (Ivon) 20.09.16 12:36
(61) miroha, Спасибо за использование моей статьи. Можно немного подправить код на SQL и саму обработку, следующим образом: создать на SQL хранимую процедуру, которая будет принимать Base64 и перекодировать его обратно в binary и ложить в базу уже двоичные данные, а так же вьюшку, которая будет делать обратное преобразование. Кстати, вьюшку можно прицепить, как внешний источник данных и впоследствии данные выбирать простым запросом 1С. В коде в 1С соответственно поменять вызов Insert на вызов хранимой процедуры, а вместо select использовать либо вьюшку в запросе либо вьюшку, как связанный источник данных.
А данная статья автора в чем-то похожа на другую мою статью, там уже все хранится не в Base64, а в бинарном виде. Работало отлично.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа