Доброго дня.
Имеется ряд xls экземпляров файлов, с одной и той же структурой данных, унаследованных от некоторого материнского файла. В общем - копии, но содержащие фактически различные - независимо собираемые данные (вообще, данные будут собираться разными людьми на разных машинах)
В помощь заносящим данные, как для занесения, так и для просмотра, предполагается сделать эти файлы способными интерактивно реагировать на вносимое в них содержимое. Сделать это планируется с помощью макросов. Как это сделать - проблемы для меня не представляет. Смотрю в перспективу. Вопрос вот в чем:
Со временем мне прийдется вносить изменения в структуру материнского файла - его доработки. Как бы переходить все к более новым версиям. Следовательно и разрозненные потомки будут нуждаться в обновлениях. Обновления , очевидно, будут касаться как самой структуры хранения данных в табличной части, так и макросов, управляющих обработкой этих данных.
Вопрос в том, как наиболее разумно реализовать механизм автообновления этой конструкции, так, чтобы пользователи отдельных файлов могли получать некий файл,  собственно обновлений, устанавливать его в нужное место и на этом все их действия по переходу к новой версии заканчивались бы. Все дальше происходило бы автоматически.
Я вижу следующее решение:
Материнский файл должен содержать минимум кода. Причем не предполагается никаких изменений этого кода при обновлении. По сути это должны быть просто ссылки на обработчики, которые будут храниться в "Движке" - некотором ином файле, который собственно и будет рассылаться в виде обновлений, переделываясь от версии к версии, и содержащий в том числе код для перевода структуры экземпляров файлов с устаревшей версией в соответствующую себе. Движок с макросами можно сделать в виде надстройки. Имя надстройки от версии к версии будет оставаться неизменным. Таким образом пользователям необходимо будет при переходе к новой версии лишь заменять движок - т.е. файл надстройки.
Вижу решение таким. Но! Никогда не создавал и не работал с надстройками. Никогда не решал подобных задач, потому не знаю, насколько предложенный мною вариант- велосипед. Как правильно решают такие задачи?
Не знаю, каким образом код отдельных экземпляров должен ссылаться на процедуры движка-надстройки. Как их слинковать, чтобы на любом компьютере, вне зависимости от структуры жесткого диска все это требовало стандартной настройки, желательно автоматической.
Прошу подсказать, кто что думает и знает по-поводу обозначенных мною вопросов.

Ну первый самый вопрос - XLS это догма? Ибо с моей точки зрения куда как разумнее нормальный инструмент ввода и корректировки данных. Если надо - со встроенными средствами генерации нужных отчётов и срезов в формате XLS.

Гы... мы все учились понемногу, чему нибудь и как - нибудь.
Я - руководитель небольшой компании, а не программист.
Времени осваивать другие программные продукты не имею, чтобы решить возникшую задачу.
Заказать программу программисту или нанять его на работу в компании мне не по карману.
Что умею - творю в свободное время по мере сил и возможностей.
А потом, в Excel как раз удобнее проверять новые идеи и дорабатывать их, все время обновляя. Минимум усилий/времени по созданию и изменению интерфейса для меня является своего рода иглой, не дающей спрыгнуть со связки VBA+Excel.

Надстройка - это постоянно действующее расширение. Разместить в надстройке макросы и модули вполне можно... но ты предполагаешь ведь и изменение структуры хранения данных? т.е. выполнение одноразовой и весьма критичной операции. Для этого надстройка, мне кажется, не подходит.
Я предлагаю тебе иное решение:
Имя файла МЕНЯЕТСЯ и содержит номер версии. При передаче он пуст - содержит формы, но без данных (ну не считая справочников). При открытии запускается процедура проверки. Если она обнаруживает наличие данных, то просто завершает работу - данные уже перенесены, фигачим. Если же данных на месте нет - процедура запрашивает местонахождения файла предыдущей версии, проверяет его структуру и выполняет импорт из него в себя всех данных. После чего для работы уже используется новый файл.
Ещё лучше, если на каком-нить служебном листе будет выделено место (ячейка) для хранения текущего статуса файла:
- пустой, данные не импортировались, запустить импорт;
- данные импортированы, начать работу;
- данные импортированы следующей версией, завершить работу.

Akina, Спасибо.
Мысли хорошие.
Я пробовал идти по этому пути уже как-то. Кое какой импорт так делал. Только версию файла прописывал не в названии файла, а все на том же служебном листе, вместе с прочей информацией о текущих настройках...
При таком раскладе возникает вопрос: "А где же будет храниться сам код обработчиков перехода от версии к версии?"
Если в тех же самых файлах, что и данные, то эти файлы получатся достаточно увесистыми со временем, даже если будут хранить не много сведений. Я склонен отделить код от собственно данных. Т.е. все обработчики как интерактивного ввода данных, так и переходов к новым версиям, сделать не в самих файлах с данными именно из соображений более компактного хранения/архивирования данных. Хоть и код не займет даже в отдаленной перспективе более 2х мегов, все-таки вопрос тут принципиальный. Допустим у меня 15 человек пользуются такими файлами. Раз в 3 дня они архивируются. Это 30 метров практически одного и того же, причем, не меняющегося за 3 дня  кода будет попадать в каждый архив. Не вариант.  Вот, от того и задумался о надстройке.
У меня, лично, так вопрос вообще решается просто для самого себя. Есть отдельный древний файл с макросами. Я его открываю, когда мне нужно и пользуюсь теми обработчиками, которыми нужно, для работы уже с другими файлами. Но я не планирую посвящать в схему работы с макросами сотрудников )) (Боюсь, что тогда совсем некому будет работать). 

Он будет храниться в новой версии файла - т.е. собсно в теле файла. По крайней мере до того, как в файл будет выполнен импорт данных. После чего код можно будет удалить (это можно сделать и программно - а для удобства весь код импорта надо разместить в отдельном модуле и удалить собсно модуль).

Слушай, у меня каждый день делается по 36 гектар бэкапа, причём если удалить дубли, он уменьшится приблизительно вчетверо. И меня это как-то совершено не напрягает. Экономить на резервном копировании - это, извини, глупость. Которую по глупости превосходит только отказ от резервного копирования.

Конечно, это несусветная глупость. Такая же, как и ежедневно архивировать одни и те же, неизменяющиеся данные. Не думаю, что в твои архивы ежедневно попадает каталог %systemroot%\system32\drivers или нечто подобное, хоть он и включен в число необходимых для восстановления системы...



А вот об этом давай поговорим?
Вот это, очень хорошая идея!
Расскажи ка, как удалить модуль программно?

Добавлено @ 09:27
Да, и все таки, 
Akina, смог бы ты подсказать, как организовать ссылку на выполнение некоторой процедуры из надстройки? Ну, для случая, когда эту процедуру нужно вызвать из кода какой либо активной WorkBook?

Это сообщение отредактировал(а) НеуФазендник - 11.8.2010, 09:36