С точностью до полубита?

vikttur,
полностью согласен. и уже таких ошибок нет
Но сам вопрос интересен

Абсолютно не принципиально. Вопрос скорее политический и условный - пора не пора. А то файл базы данных так разросся, что промежуточное сохранение заставляет ждать по минуте, пока он перепишется на диск. Вот и думаю, что нужно какие-то листы периодически помечать на перенос в отдельные файлы и подгружать их обратно только по мере их надобности. потому что балластных данных\листов, которые могут не использоваться в текущей сессии работы с файлом,  - 90%.
При этом плодить лишние файлы с листами, на которых данных с гулькин нос, нет никакого смысла. Т.е нужнен условный, можно даже относительный, а не абсолютный оценочный механизм веса различных листов.

БМВ, В макросе это будет не тривиально реализовано и по быстродействию не айс, т.к задействует FSO. Проще уж тогда выделить рабочую область и через specialcells и len подсчитывать число символов. Но это опять же - скрытый цикл со всеми вытекающими по быстродействию. Когда один лист - оно не проблема. А когда листов сотни, да и операция проводится с некоторой периодичностью, это уже подгрузочка ЦП.

Поздравляю, вы дозрели до полноценной базы данный. Пора прощаться с детством в Excel .

Андрей, прощание исключено. Я уже дано это понял. Причина банальна. Эксель в себе содержит мощный практически безграничный инструментарий, который при расставании придется ручками прописывать так же бесконечно в каждом своем приложении. Это очень трудоемко и потребует кучу времени на изобретение ведлосипедов, уже созданных в эксель. У меня мощнейший обработчик моей мощной БД весит всего 2,7 Мб. Будь он отдельным приложением, то весил бы мегов 300 и не факт, что мне удалось бы за жизнь прописать и отладить все те возмозможности, которые он дает.
Я давно обратил внимание, что любой язык программирования не может быть полностью универсальным и эффективным для решения абсолютно всех вопросов. У Екселя есть свои изъяны. Да, он не тянет быструю обработку таких мощных объемов данных. Но плюсы тоже имеет несомненные. Я их назвал. Поэтому переход к любой системе - это всегда определенные жертвы и определенный компромисс. И естественно мастерство программиста, выкручивающегося и скглаживающего продуманными алгоритмами недостатки конкретного движка. Несколько раз серьезно раздумывая о том, уходить или не уходить от Экселя, я все же пришел к выводу, что уход в целом для реализации моих задач не целесообразен.

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

Вопрос в быстродействии. Имеющийся вариант называется - для бешенной собаки семь верст не крюк. Мне нужно изящное решение, а не гора процедур и 1000 строк кода вместо 10 символов. По идее Эксель должен где-то хранить размеры своих объектов. Ведь он оперирует памятью, выделяемой под их хранение\отображение.

С этим согласен. Но тут пока нет проблемы, если их хранить тупо в экселевском формате и не заморачиваться, бегая впереди паровоза. Ну будет отдельный каталог с файлами эксель. Делов то...
Не изящно, странно, за то работает А на большее не претендую, т.к по сей день езжу на Москвиче 2140 и поьзую WinХP и Windows Commander на ряде своих компов и меня это вполне устраивает! Не вижу смысла в прогрессе ради прогресса, если существующие инструменты на 100% выполняют свои задачи.

Только Microsoft не озаботилась ни предоставлением доступа в объектной модели для VBA, ни свободным доступом к документации API вызовов dll исполняемого кода.
P. S. Новая тема для курилки

Вызов команды Dir, мне кажется, будет в 100 раз более медленной операцией, (т.к это далеко не тривиальная операция по своей сути)нежели этот элементарный цикл по расшифровке содержимого каталога. Кстати, не вникал, как там современно через FSO это делается. У меня это реализовано именно вызовом досовской Dir и перенаправлением результата в txt файл, который dir генерирует в дурацкой кодировке, в которой часть символов "улетают" в некорректность при попытке их считывать штатными процедурами чтения из текстового файла. Поэтому приходится еще и анализировать ASCII код каждого символа и через CASE ретранслировать. В общем, зоопарк отдыхает с расшифровкой некоторых свойств оглавления каталога. Уже не помню, каких именно. Реализовано было лет 15 назад. Работает и работает по сей день без вопросов и я не парюсь, как оно там и чего.

Пробовал. Сравнить есть с чем объективно. НО! Консерватор. Не расходую новых ресурсов на уже решенные вопросы без острой нужды.
За альтернативу благодарю. Я возьму на заметочку - скопирую себе в альбом заготовочек, чтобы в случае чего по справке долго не рыскать!

БМВ, Чтот я в дебри залез.
Разбираю первый Ваш код. Нет у меня зипа. Переиначил код под Rar:
cmd = """C:\Program Files\WinRAR\RAR.exe"" I=xl\worksheets -r F:\DIN\Базаэксперименты.xlsm"
Вызов возвращает пустую строку. Пробую отдельно из командной строки запускать. Отрабатывает и закрывается окно. Не вижу результата. Пробую просто раром открыть вручную - он не открывает xlsm. Оно и логично. Если расширение вручную сменить  - откроет. А так вроде б и правильно ругается на тип файла. Короче, запутался я.

Neufazendnik,  При всем своем уважении к RAR и Рошалам, много лет им не пользуюсь. Уже все ключи забыл. Портативная ругается что архив не архив :-(

Ну если 7zip или что-либо умеющее извлечь содержимое отсутствует, то кроме как копирования листа в новую книгу, записи и извлечения размера файла, который относительно скажет о размере информации вариантов у меня в голове нет.

Neufazendnik, Чем же вам так 7zip не угодил? :-) . Про ZIP не знаю, но кто мешает вам попробовать? Но в целом странно, что через GUI WinRAR не испытывает сложностей , а консольный уже пасует перед разрешением.