Преамбула
До сего момента в нашей организации в самописной конфе использовался стандартный механизм из типовой торговли — ХранилищеДополнительнойИнформации, но когда объем базы достиг 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/
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
минус за введение в заблуждение 1Сков
надо было перенести часть данных в отдельную файловую группу на отдельные диски
Не понял
зачем это нужно ❓
«Размер базы 1с уменьшился в 4 раза» разве не появилась база SQL размером 3/4
Появилось лишнее звено
2 Гилев. Мне показалось лишним включать в передачу этих данных сервер приложений, да и тестовая база будет разворачиваться гораздо быстрее, т.к. восстановить нужно будет только данные, которых существенно меньше.
2 Evg-Lylyk. На самом деле 2я база стала даже больше, т.к. не использовался механизм встроенного сжатия. Размер тут как раз не важен, важна скорость получения данных. А она в моем случае сильно страдала из-за большого объема файла базы данных.
(3) Непонятно какой прирост это дает в каких случаях (и дает ли вообще)
При помещении в реквизит хранилище можно не сжимать.
Мне кажется задачу можно и нужно было решать в рамках 1С8
насколько я понимаю из описания сканы хранились непосредственно в базе, а второй способ (сканы хранятся на дисках, а в 1С хранятся пути к ним) пробовали? Если, да то хотелось бы увидеть комментарий по этому поводу.
я так понимаю, что после установки новой базы Вам и схему обмена с головой пришлось менять. Или тащите старым способом, а потом в базу хранилище сканы отправляете?
почему для файлохранилища выбрана скулевская база, а не что-то из 1С? На мой взгляд, при необходимости 1Совскую базу легче корректировать.
2 tsd
1. У нас 150 тыс элементов, для файлового хранилища не самый лучший вариант на мой взгляд.
2. Схему обмена с головой поменяли незначительно, но тем не менее — да, поменяли.
3. При таких объемах данные нужно хранить в какой-либо СУБД, первоначально я посматривал в сторону документо-ориентированных СУБД, но понял что моей квалификации на их обслуживание явно не хватит. В итоге выбрал то, что знакомо больше и уже проверено.
4. А зачем? Идея была именно разнести обращение к данным 1С и прикрепленным файлам, вообще убрать их из 1С структуры, т.к. скорость их получения не критична, в отличие от тех же отчетов.
2 Evg-Lylyk Прирост дает, обратите внимание на первое сообщение Гилева, это по сути тоже самое, только подразумевает хранение файлов в той же базе 1С, но в другой файловой группе в рамках той же базы SQL. Мы с админом данный вариант обсуждали, но поскольку за 3 месяца мы прибавили 15 Гб файлов, то приняли решение убирать их вообще в отдельную базу. Проще и тестовые базы поднимать и обслуживание производить. Файлы же по сути не являются критичными для бизнеса данными, в отличие от документов.
(6) Это все на одном сервере? если да, то можно база на 1С и работа через COM.
что значит разнести!? если просто разнести по базам на одном компе одном диске это ничего не даст.
здесь одни сложности относительно изначального варианта
Описание запутывает, если бы его не было, тогда проще придумать объективные причины сделать так. А так как есть много вопросов почему пользователи обращаются так часто к этим файлам (200 юзверов 3 обращ./сек к файлам по 2 Мб итого 6 Мб/с для RAID ерунда).
(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С:Предприятия, но кто его знает 😉 .
Думаю минусовать не за что… Человек предложил свой метод реализации, в чем то он хорош, в чем то плох…
(7)
Базы разнесены на разные дисковые массивы, и таки выигрыш производительности все же достигнут.
Вполне возможно что описание запутывает, мой косяк — в ближайшее время переделаю.
(8) Это вообще самописная конфигурация, имеющая обмены с 1 УТ, 2 БП и 1 с самописной системой в голове.
2 сервер) база 1С + SQL в которой содержался бы один справочник, в котором хранились бы сами файлы в ХранилищеЗначений без сжатия.
Да, но тогда бы пришлось создавать COM не ADO, а 1С для доступа ко второй базе, ИМХО такое решение бы скоростью не отличалось точно. А так каждый пользователь напрямую запрашивает данные в SQL сервере, не трогая сервер приложений. Сегодня база будет под полной нагрузкой, опишу результат.
подвожу итог
фразы вроде «Мы с админом данный вариант обсуждали» означают, что обоснованности нет, есть только самоуговаривания как лучше
реальных тестов — нет
сделали и заработали, т.е. пронесло
однако делать вывод о том, что стало лучше смешно, ведь задействовали новое железо, а вот это куда существенней
вцелом я допускаю такую реализацию, даже закроем глаза на пресловутое ЛС,
НО не надо это подавать как ПРАВИЛЬНОЕ решение
это Ваш частный случай
инетерсно что будет, когда кто-нибудь пойдет по вашему способу, но например оставит базу на том же сервере…
или еще где накосячит
минус не за то, что у вас работает, а что этому учите всех налево и направо
без обид
А объясните мне насколько выгоднее хранение изображений в SQL чем просто хранить отдельной папке?
Появляются только накладные расходы на получение информации из базы SQL и сохранение на диск во временный файл. В чем плюс?
Описание обновил, надеюсь так будет чуть понятнее, если что — поправите плиз.
(10)
Я и админ ориентировались на счетчики производительности системы, к сожалению, скриншотов нет, т.к. задача была не теоретической, и решение принимать нужно было быстро да и разворачивать тестовую базу с новым решением попросту негде.
однако делать вывод о том, что стало лучше смешно, ведь задействовали новое железо, а вот это куда существенней
вцелом я допускаю такую реализацию, даже закроем глаза на пресловутое ЛС,
НО не надо это подавать как ПРАВИЛЬНОЕ решение
это Ваш частный случай
инетерсно что будет, когда кто-нибудь пойдет по вашему способу, но например оставит базу на том же сервере…
Стало лучше — да, задействовали новое железо — тоже да. Но тем не менее база находится на том же сервере только на другом дисковом массиве. Более того, в ближайшее время админы будут пересобирать рейдмассив и все временно переедет на один диск, будет интересно глянуть на результат этого кошмара.
По поводу ЛС — давайте все же не будем закрывать глаза и разберемся, что же тут не так. Есть база самописная 1С доступ к которой осуществляется целиком и полностью только через сервер приложений 1С и есть внешняя база SQL доступ к которой осуществляется по ADO. Если бы вторая база была бы 1Ская, я бы понял праведный гнев.
И на последок — не бывает ПРАВИЛЬНЫХ решений, есть лишь оптимальные с точки зрения доступных средств и финансов на определенный момент времени. И накосячивший программист способен накосячить не только через ADO, но и внутри 1С так, что потом несколько нормальных спецов потребуется.
(11) Тут только ИМХО, если что более опытные меня поправят. Все целиком и полностью зависит от масштаба бедствия: сколько пользователей, каков размер базы и таблицы хранилища файлов, сколько элементов в данной таблице.
Если изображений не много, то можно хранить и в самой базе.
Если их довольно большое количество как по числу файлов вообще так и по размеру, то СУБД — оптимальное решение. Я читал о разных способах решения, в т.ч. о хранении в файловой системе и на ftp. В итоге люди ушли от этого, т.к. поддерживать целостность данного массива довольно сложно и скорость доступа этого решения на больших объемах была крайне мала. Яндекс вам в помощь.
А вариантов хранения в СУБД может быть несколько, самый простой случай создать файловую группу, перенести туда вашу таблицу и вынести эту таблицу на другой физический дисковый массив.
(12) нет времени, негде тестировать — это все частности
объективных тестов не было!
еще раз, мне не нравиться ваше «учить жизни» 1сков нештатными средствами, как следует не оттестировав штатные
это мое личное мнение, а придумать почему так сложилось можно все что угодно, вплоть до религии,
некоторые на инфостарте вообще всюду предлгаюат юзать нетфреймворк, бог им в помощь
(13) Знаком со всеми перечисленными вариантами хранения, просто непонятны плюсы от использования SQL. Моё мнение что от использования SQL получаем только дополнительные минусы о которых я уже писал:
— накладные расходы на доступ к базе SQL
— накладные расходы на сохранение файлов на диск перед любыми действиями с ними
Хранение сразу на диске не вызывает никаких проблем с контролем целостности по сравнению с внешней базой SQL. Производительность файловой системы достаточна при использовании отдельных папок и ограничения количества файлов в одной папке. Вот я и хотел уточнить о наличии дополнительных плюсов и минусов о которых мне неизвестно.
(14) Штатные методы хранения изображений в базе мне не нравятся в связи со сложностями в резервном копировании и последующим восстановлении из резервных копий.
(14) Есть проблема. Есть вариант решения проблемы. Причины по которым штатные средства не подходят описаны. Причинно следственная связь прослеживается. Включаться же в спор между вами и ярлыком который на меня был повешен считаю излишним.
(15) Файловая система как раз не дает гарантии целостности. Про FAT говорить излишне, а NTFS, насколько мне известно, гарантирует целостность только MFT, а не содержимого файлов. Но с другой стороны, если необходимо получить эти изображения где-то в web, то такой вариант несколько проще.
(16) Какой контроль целостности имеется в виду?
Я имел ввиду ссылочную целостность.
Нам ничего другого не требовалось так как присутствовал:
1. Бекап изображений
2. Бумажный оригинал
Но за 10 лет использования не пришлось прибегать ни к одному из этих вариантов.
Больше про целостность ничего сказать не могу.
(17) Имелась ввиду целостность данных, когда происходит сбой во время записи данных.
Ссылочная целостность как раз не гарантирована ни моим не вашим способом, удаляем файл или запись во внешней таблице и ссылочной целостности нет.
Думаю что такой подход имеет правона существование.
Какие вижу плюсы:
1. Скорость восстановления «рабочей» базы не обремененной хранилищем значительно выше.
2. Обращение к данным в отдельной базе возможно из нескольких конфигураций, следовательно отпадает необходимость в дублировании.
Минусы:
Скорость (получения данных из отдельного хранилища), скорее всего будет ниже.
А как насчёт борьбы с «потеряными» записями? Они будут постепенно образовываться в базе (хранилище) с отсутствующими ссылками на них…
(19) Да по идее не должно оно быть ниже, 1 звено из цепи уходит. Поднял старую базу в качестве тестовой и проверил, результаты в аттаче.
(20) допишу чуть позже, работы многовато 😮
Ну и каков стал размер базы картинок хранящихся в sql А не в 1с*? хочется узнать разницу.
(23) вырос с 35 до 42-43Гб.
to (20) Теоретически они могут быть и в единой базе. Так что это тема «цены вопроса»? Для каждого в конкретном случае она своя.
to (24) А увеличение это не сжатые «картинки» я так понимаю…
Вполне достойное решение, имеющее право на жизнь.
Штатные механизмы и возможности — это конечно хорошо, но иногда временные и бюджетные рамки не позволяют сделать все «идеально».
В конкретном данном случае этот вариант — хороший выход из положения. И мотивация автора в данном случае полностью понятна.
ндя… радует что 8осьмерошнику идея отвязать сопросодительную «незначимую» инфу вынести з апределы базы пришла в голову только сейчас, в то время как 7-ки это делали давно… 😉
.
не понял только одного? в чем вкусности решения?
Тоже способ хранения. Однако по своему опыту делаю всё на внешних файлах — BLOB как-то не по душе … А в рамках 8.2 с файлами работать стало проще, не надо теперь шару открывать на сервере.
Для поддержания ссылочной целостности у меня крутится регламентное задание на проверку и очистку битых.
Можно подробнее про обмен с головой? Каким образом передаются файлы?
(27) Справедливости ради, заметим, что помещать бинарные данные в 1С базу версии 7.7 нельзя, так что лирическое отступление странное. Вкусности решения, описаны выше: более быстрый бекап/восстановление тестовых баз, меньше нагрузка на RAID с базой.
(29) Через XML. Насколько я помню, там используется XDTO пакет. Точнее не скажу, не я писал.
— это откуда такое мнение???
(31)Если не сложно, напомните мне, насколько я помню, кроме как финта с ушами в виде сохранения объекта в виде строки с внутренним представлением встроенной процедурой, другого способа нет. То есть напрямую загнать бинарные данные в реквизит не получится, или я не прав?
Тоже интересный способ…
Коллеги, в данном примере формат сохранения в SQL базу идет 0xFFD8FF — это живой JPEG.
А, кто знает формат хранения в SQL сервере изображения записываемого самой 1С ?
Прекрасный пример, приспособил под собственные нужды. Спасибо автору.
(28)при больших нагрузках sql ado stream быстрее чем file acces ИМХО….
если процы мощные (там где сжимется… если это не управляемое приложение — то на клиенте… а там ваще Г может быть)
можно сжимать (deflate).. при записи задержка.. при чтении иногда быстрее
+ но надо анализировать сжимать не сжимать ….
(34)deflate на файл…
Автору — спасибо! Очень помогло, в нужное время в нужном месте. =))
Пытаюсь адаптировать для PostgreSQL.
Сделал табличку
при попытке обратиться через Recordset к полю Object вываливаеться с ошибкой
Может есть какие мысли?
(39) KV1s, К сожалению, с данной СУБД ни разу не сталкивался. Попробуйте задать вопрос на сайте соответствующего сообщества, наверняка есть подобное как sql.ru
(40)
Вроде разобрался, правда через Ж
Использовал ADODB.Command с параметрами для добавления через AppendChunk и драйвер ODBC.
Ветка на соответствующем форуме
(41) KV1s, Почему же через Ж, ничего кривого в той ветке я не увидел.
А для управляемых форм подойдет?
(43) Shum23str, Сама конфа работать, конечно, не будет, а внутренняя часть, отвечающая за подключение к SQL базе и получение файла — да.
Добрый день, при попытке закрепит файл, ругается и выдает ошибку
Запись файлов в хранилище возможна только на рабочей базе
Не удалось поместить файл в хранилище через ADO соединение
Насколько я понял, что надо указать путь к ИБ. Вот только я думаю, как его указать, скорее всего мой вариант не верный
Функция ПоместитьФайлВХранилище(СоединениеАДО, УникальныйИдентификаторФайла, ПолноеИмяФайла) Экспорт
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), «»»», «») <> «File=»»C:\InfoBase»»; Usr =»»Админ»»;») Тогда //РУЧНЫЕ ИЗМЕНЕНИЯ
#Если Клиент Тогда
Сообщить(«Запись файлов в хранилище возможна только на рабочей базе», СтатусСообщения.Важное);
#КонецЕсли
(45) dynamite, Добрый день! На первый взгляд ошибка в указании строки соединения. Введите в табло СтрокаСоединенияИнформационнойБазы() и проверьте, не забудьте про функцию НРег в условии.
(46) Сможете описать в примере… если честно я не так силен в программирование…
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), «File=»»C:InfoBase»»; Usr =»»Админ», «») <> «СтрокаСоединенияСИнформационнойБазой») Тогда //РУЧНЫЕ ИЗМЕНЕНИЯ
после чего выдает ошибку
«Запись файлов в хранилище возможна только на рабочей базе»
(47) dynamite, Если еще проще, то запустите отладчик, установите точку останова на условии
исследуйте левый операнд в условии
поместите в правую часть.
Суть условия — исключить выполнение функции в тестовой базе.
(48)Silenser, я так понял то что я делаю не правильно да?
Если (СтрЗаменить(НРег(СтрокаСоединенияИнформационнойБазы()), «File=»»C:InfoBase»»; Usr =»»Админ», «») <> «СтрокаСоединенияСИнформационнойБазой») Тогда
(49) dynamite, Вы издеваетесь?)
(50) TMV, а мне зачам издиватса, я же ясно выразилса что я не могу сделат… если можете могли бы дать просто вариант как написать…
Просто мне очень надо этот функцыанал
(51) dynamite, кидайте всю процедуру — глянем
Показать
Попробуйте этот кусок закомментировать
Была похожая проблема, решил файлы хранить просто на сервере в скрытой папке, а в 1С записывалась ссылка (путь) к данному файлу, естественно имя файла менялось программно чтобы можно было хранить файлы с одинаковым именем.
Если его закомментит то проблема решает сразу… пробовал
Только вот при этом все ли нормально работает или нет, как определит?
И вообще это кусок кода за что отвечает?
(54) TMV, Я посмотрел… там появляется проблема №1 что нельзя указать название файла, так же мы не можем изменят или назначать имена
(56) dynamite, Вы читаете то, что вам пишут? См. 48 коммент.
(58) Да да уже разобрался с этим, появился другой вопрос.
С изображениями как такого проблем нету. Все работает как по маслу. А вот при работе с файлами сохраняет без проблем ну вот при открытие выдает ошибку
{ОбщийМодуль.РаботаСФайлами.Модуль(850)}: Поле объекта не обнаружено (ИДФайла) Хранилище = Новый ХранилищеЗначения(ПолучитьДанныеИзХранилища(СоединениеАДО, ОбъектФайла.ИДФайла, СокрЛП(ОбъектФайла.ИмяФайла)));а в чем тут проблема?
(59) dynamite, Скорее всего в списке нет указанного поля, нужно его добавить через настройки списка в режиме предприятия.
Изначально файловую помойку изображений хранили на файловом сервере, сплошные проблемы прав и доступа — каменный век для большого количества файлов.
Хранить файловую помойку в загруженной базе мы посчитали не серьезным и вынесли в отдельную базу SQL.
У нас картинки и сканы документов хранятся в отдельной SQL базе, доступ на чтение через внешний источник данных, запись как в примере . Все функции работы с внешней базой на сервере 1с.
Плюсы
Скорость работы базы выше, при активной работе с документами нет нагрузки на основную базу.
Резервное копирование основной базы быстрее, размер копий меньше со всеми вытекающими.
База картинок в нашем случае общая на несколько баз, каталог на сайте тоже с нее читает.
Минусы
Размер базы 3x от размера картинок( зато нет файловых операций)
Администрировать приходиться на одну базу больше.
В случае отказа базы картинок , в основной базе их нет, но база продолжает работать.
Необходима обработка для переноса имеющихся картинок и доработка конфигураций.
Здесь есть пример отталкивался от него, полгода работает стабильно.
(55) reeds, А по подробней не мог бы написать о таком спосабе хранения файлов, появились ли в дальнейшем проблемы и как именно реализовывал, а то все пишет только о внешних СУБД.
P.C. можно и в личку
(61) miroha, Спасибо за использование моей статьи. Можно немного подправить код на SQL и саму обработку, следующим образом: создать на SQL хранимую процедуру, которая будет принимать Base64 и перекодировать его обратно в binary и ложить в базу уже двоичные данные, а так же вьюшку, которая будет делать обратное преобразование. Кстати, вьюшку можно прицепить, как внешний источник данных и впоследствии данные выбирать простым запросом 1С. В коде в 1С соответственно поменять вызов Insert на вызов хранимой процедуры, а вместо select использовать либо вьюшку в запросе либо вьюшку, как связанный источник данных.
А данная статья автора в чем-то похожа на другую мою статью, там уже все хранится не в Base64, а в бинарном виде. Работало отлично.
(61) А все таки, подскажите пожалуйста, в чем проблема с правами доступа при хранении картинок на файловом сервере? В чем сложность была дать пользователю, под которым работает 1С, права на чтениезапись файлового каталога?
В нашей организации подобная проблема(усугубленная тем что сеанс 1с в толстом клиенте нормально не освобождает память после просмотра картинки и некоторые терминальные 1с отжирали до двух гб ОЗУ) пошли несколько иным путем. Картинки записываем на ФТП в каталог с наименованием = УИД элемента владельца, наименование картинок тоже УИД. Основное изображение текстовое поле. В папку куда записываются файлы смотрит nginx и показ изображение идет в поле html документа. Так мы избавились от жора памяти и урезали базу на 40 ГБ.
Уточнение, на всякий случай: при отправке команд в Postgre имена полей и таблиц нужно заключать в двойные кавычки, в то время как MS SQL нормально воспринимает их и с кавычками и без. В своей библиотеке подсистем использовал формат команды с кавычками, т.к. новая подсистема более универсальна, умеет работать и с MS и с Postgre.
скачал, интегрировал код — теперь каждому клиенту нада устанавливать скульного нейтив клиента
нельзя было сказу на стороне сервера это решить?
решение кривоватое от слова совсем
(67)ODBC драйвер для MS SQL входит в поставку Windows, не нужны никакие дополнительные драйверы, все и так работает. В новой версии, которая более современная и поддерживает клиент-серверный режим работы, работа с SQL сервером ведется с сервера. Основная же идея этого решения — как раз исключить сервер из цепочки по передачи файлов, чтобы напрямую работать с MS SQL.
тогда вышли плиз 30 лицензий на подключение к msssql. адрес ты знаешь
(68) если это odbc, то можете бросить в меня камнем. не вводите людей в заблуждение
(69) Поздравляю, вы раскрыли мой заговор по введению всех в заблуждение. Пожаловаться можно и вот . Далее разрешите откланяться.
(68) а в документе вашем тестовом вроде вместо ОбработкаВыбора
Показать
не должна быть ОбработкаОповещения ? Ведь везде оповещение а не выбор
(68) + еще при открытии базы вы чистите папку EXT_FILES а пишете временные файлики в папку EKIS_EXP ? Ошибка ?
(71)Не было тогда оповещений 🙂
(72)Скорее всего. Писать и чистить при открытии нужно одну папку, чтобы она не засорялась. Как вариант можно создавать временные файлы, они чистятся сами.
(73) это когда? в 8.1 уже были. Вы не подумайте чего просто Оповестить не обрабатывается ОбработкойВыбора )
(74) да и наверно еще после помещения в sql табл грохать папку с файлом… А то что даже при навигации по файлам каждый раз создается папка и наименованием уникальным и файликом не сильно тормозит клиента?
(75) Это понятно, что не обрабатывается. Мне сложно отвечать на вопросы по коду, которому уже много лет, я уже просто не помню. К сожалению.
(76)Нет, и дает одно преимущество: многие просмотрщики имеют возможность открыть следующий файл в каталоге, при таком подходе файлы перемешиваться не будут. И потом, каталог же чистится.