И даже если он и есть, не факт что он развернется...

Я бы хотел иметь интсрумент, который бы собирал статистику по:

Статистика по работе с базой:
1. Рост/измененния файла базы. Не важно серверная или файловая.
2. Статистика по вводимым данным - справочники, документы.
3. Количество пользователей работающих в базе.
Блокировки(опционально)

Обслуживание базы данных.
1. Возможность создания и доставки - по мылу, просто копированием - технологического журнала.
2. Не полноценное тестирование и исправление а именно сжатие и реиндексация.
Тестирование в режиме тестирования и из конфигуратора и chdbfl. Опять же с доставкой результата куда-то в одно место. И анализ его. Хотяб есть ошибки нет ошибок.
3. Наличие какого-то агента, чтоб можно было срубить открытую 1Ску у пользователя. Чтоб такое же мог сделать и скрипт архивации. Ну и чтоб можно было через "это" сообщения рассылать. Так же, желательно чтоб этот агент мог показывать работает там 1Ска или просто открыта. Соответсвено на основании этого и принемать решение о возможности убивства процесса. В общем аналог того что есть в консоли сервера.

Внутри базы.
1. Востановление последовательностей - Расчетов, НУ УСН...
2. Удаление помеченных объектов.
3. ...иметь какую-то возможность, запуска произвольного кода. Ну тоесть указываеш какую-то внешнию обработку, и запускает.
4. ...какая-то возможность пакетной обработки документов/справочников - какой-то аналог групповой обработки справочников и документов, но чтоб настроить его можно было в этой конфигурации а выполнялся бы он в другой.

Снаружи баз
1. Былоб не плохо иметь какой-то интерфейс к счетчикам производительности Windows. Пусть не всем - хотя б просто - диск, CPU, оперативка.
2. Чистилка кэша - тот что в профиле пользователя. Это можно б было возложить на "агента".
3. Управление списком баз пользователя - тот который лежит в профиле. И возможность переключения - общий список баз/ "часный" список баз. Режим запуска и совместимости.

Всё это было б интересно, еслиб оно вело удобный лог. Чтоб оно могло анализировать ситуации - рузультаты тестирования, что-то из технологического журнала... и предстааляло это "на одном листе". При этом, чтоб имелась возможность посмотреть иторию работы с базой.
Ну и в придачу - возможность расылки оповещений и сводных отчетов, например по мылу.

Насчет архивации.

1. было б не плохо, иметь выбор чем архивировать - rar(всетаки не бесплатен), 7zip...
2. Логирование. Перед началом посмотреть, открыт ли файл или нет - вывести в лог.
Попытаться закрыть - результит в лог.
Опять смотрим есть открытые или нет - в лог
Архивация - в лог.
В лог писать полностью все. Начиная от имен/путей, заканчивая размером базы до и размером архива после.

3. Возможность заливки куда-то.
Простое копирование или же куда-то на FTP(например на NAS сервер). Опять же логирование.

4. Возможность удаления старых архивов. Желательно чтоб критерий старости можно было б задавать. Ну например оставлять архивы за прошлые месяца только один за неделю. Ну смыл, думаю, понятен.


Ещё комментарий.

Бальшую часть по обслуживанию баз 1С в любом случае придется писать на JScript/VBScript и WMI. В среде 1С можно разработать только "морду" для управления этим делом.
Отсуда...для чего писать конфигурацию? На мой взгляд, былоб удобнее написать внешний инструмент - обработку - которая бы и была "мордой". Всё что можно вынести из ней в скрипты туда и вынести.
Для запуска по расписанию использовать виндовый же шудулер. Для сбора данных... ну наприме .mdb файл или SQL Express, вариантов много.
Тоесть завести некий иструмент с расширение за счет плагинов - новых Windows скритов и внешних же обработок 1С которые бы мошли обрабатывать результаты первых.

FixinThe Dim!Для сбора данных... ну наприме .mdb файл или SQL Express, .
У 1С очень хорошие инструменты для построения отчетности (СКД например).
А для чего тут разляпистое СКД?

FixinПоэтому использовать MDB для накопления данных не есть гут...
У нас SQL-версия 1С в центре, соответственно и базу по управлению базами можно разместить в 1С-SQL формате. Будет летать намного шустрее MDB и не нужно думать насчет интеграции, протоколов обмена. Все родное, нативное и, тем не менее, быстрое.
Каков объм хранимых данныех - да крохи. Поэтому формат особо значения не имеет. Хоть в .csv. Хоть свой формат в том же .txt

Я о другом.
Кто будет собирать данные с удаленных баз(какой механизм-то)? Я предлогал орагнизовать некоторого "клиента" который бы и занимался этим. Тоесть, если есть n-серверов то каждый отчитается за свои базы и сбросит куда-то в "центр" данные - в каком виде?
В принцепе, можно же потом эти данные импортировать в каку-то конфигурацию и пользуй свое СКД сколько хочеш, можно сразу через OLE закидывать...
Я не вижу смысла тянуть все это в конфигураци. Т.к. информация весьма разнородная. Да и пока нету даже модели - исходя из чего писать?

Как вариант, можно заняться чем-то типа собирания и объединения разных открытых инструментов - на основе внешних отчетов, на основе виндовых скриптов. Создание чего-то вроде стандартной библиотеки/репозитария. С описанием, со стандартным вызововом... А по мере того как сложится какой-то костяк системы тогда уже думать о конфигурации.

Конфигурация не интересна - лично мне - потому как в рамки конфигурации не вписывается концепция плагинов. Допиливать конфигурация тоже не вариант, потому как я внес одно изменение, а ты другое. И что тогда? А ситема плагинов даст возможность вести несколько вариантов одного вопроса параллельно. А там уже каждый для себя определит набор нужных ему инструментов(плагинров).

Да, можно для этого использовать внешние обработки. Но это не то, потому как с помощью обработки ты не внесеш изменения в структуру базы. Например, где будет хранится статистические данные, в каких разрезах... ? Очевидно что это справочники и регистры, но какие, какова их структура... Если описывать это просто руками - типа прочти и внеси сам - муторно это. Опять же, как поддерживать эти плагины? Я назвал объект так, а ты эдак, версионность...

FixinЕще вот подумал, что хочу из заданных баз получать общее расписание регламентных обработок....

Вот потому-то и говорю, что у каждого свои требования к функционалу и одной конфигурацие это не покрыть. Или она будет разляписта как УПП. Опять же кто её будет подерживать, развивать.
А система с плагинами - не обязательно на платформе 1С - это севсем другой разговор. Достаточно организовать ядро системы, а там - если проект окажется интересным - народ сам будет дописывать/допиливать новые плагины - на свой вкус.

На чем если не на 1С?
Интерфейс: .hta, есть тот же Python...
Отчеты: ...HTML, Open/Microsoft офис...

FixinУ нас SQL-версия 1С в центре, соответственно и базу по управлению базами можно разместить в 1С-SQL формате. Будет летать намного шустрее MDB и не нужно думать насчет интеграции, протоколов обмена. Все родное, нативное и, тем не менее, быстрое.

Это кто кому родней доводится - 1C и MS SQL ?????
Скорость... - просто так сказать что SQL быстрее файловых баз(например Access) это невежество. Так как есть много "Если" и "Но". Почитай сравнения и тесты - обрати внимание на объем данных.