Проблемы с псевдокомпиляцией *.mdb в *.mde
Выполняю преобразование *mdb файда в *.mde. Access создаёт файл db1.mdb, потом создаёт файл *.mde, но затем выдаёт сообщение, что не удалось создать *.mde - файл и удаляет *.mde и db1.mdb - файлы. Причём, если запускать редактор кода (насколько я знаю, в этом случае при ошибках, критичных для компиляции, в коде будет показано место ошибки) никаких сообщений об критичных ошибках нет, но картина аналогична той, что описана выше. После выдачи сообщения об ошибке Access не "вываливается", но продолжает нормальную работу. Из *.mdb файла приложение выполняется без проблем.
Особенности программы:
Подключены библиотеки Microsofr Common Controls 2.0 (mscomct2.ocx) и Microsoft Scripting Runtime (scrrun.dll).
Ссылка на объект из scrrun.dll FileSystemObject указана следующим образом:
Dim Fso As FileSystemObject
Set Fso = CreateObject("Scripting.FileSystemObject")
Ссылки на объекты File и TextStream указаны ранним связыванием.
Кроме того, в исходном *.mdb файле нет 2 таблиц, но есть на них ссылки в коде. Таблицы эти создаются динамически при первом запуске программы на машине пользователя. Одну из этих таблиц я могу внедрить в *.mdb - файл - она всё равно пересоздаётся при запуске приложения. Вторая таблица играет роль *.ini - файла, и поэтому её нежелательно оставлять в *.mdb во время псевдокомпиляции.
Если кто знает, как откомпилить, Help.
Тут хорошо бы всю базу перекомпиллировать.Debug->Compile<Имя проекта>.
Еще можно посоветовать взять пустую базу и импортировать туда все свои модули, формы, отчеты (копировать вставить), говорят таким образом можно избавиться от неокторых непонятных глюков. Полученную новую базу следует скомпиллировать.
По идее, mde это скомпиллированная mdb, токо без лишнего кода VB. Если при преобразовании возникает ошибка, то вероятно все-таки есть ошибки/нестыковки в коде. Трудно предположить что-нибудь другое. Теперь почему mdb при этом может спокойно выполняться. Тут такая особенность. по умолчанию (Tools/General/Compile On Demand=True) Access компиллирует только тот код, который необходим для выполнения текущей процедуры. В связи с этим, можно иметь ошибку в модуле, но если этот кусок кода не работает во время использования mdb, то он его и не компиллирует.
Тут хорошо бы всю базу перекомпиллировать.Debug->Compile<Имя проекта>.
Еще можно посоветовать взять пустую базу и импортировать туда все свои модули, формы, отчеты (копировать вставить), говорят таким образом можно избавиться от неокторых непонятных глюков. Полученную новую базу следует скомпиллировать.
В модулях ошибки точно нет. Во-первых потому, что приложение я только дописывал, а до этого его компилили, а за тот код, который я писал, я ручаюсь, да и перепроверил я его 100 раз. К тому же в режиме интерпритатора при тестировании облазили все модули, но ошибки не обнаружили. Произвести компиляцию из меню отладки пробовал - среда ничего не сообщила. Не знаю, чем это должно закончиться - при выборе пункта Debug/Compile <имя программы> ничего не происходит и не создаётся. Жаль, что не знаю особенностей среды VBA. В VB обычно при компиляции указывается место ошибки, а, накрайняк, можно запустить приложение из среды с предкомпиляцией (Ctrl+F5), и тогда уж точно среда укажет, что ей не нравится. Есть ли в VBA что-нибудь подобное?
Действительно, создал новую БД, всё импортировал туда и... ОТКОМПИЛИЛ!!!! Без проблем!!! Прямо смысловые галюцинации какие-то!!!
ОГРОМНОЕ СПАСИБО!!!:D
Дело видно кроется в интелектуальном механизме VBA компиляции программных модулей. Он следит за их изменением и ставит соотв. галки что необходимо перекомпиллировать, вероятно иногда у него едет крыша и он никак не хочет перекомпиллировать модуль с ошибкой, считая что с ним все ОК и компиллировать его не надо. Один из способов заставить его принудительно перекомпиллировать всю базу как раз и состоит в исморте в новую базу. Есть еще одна недокументированная команда, которой следует пользоваться когда база порушилась и не хочет запускаться, тогда общая схема действий такая:
после импорта в чистую базу сделать /decompile(т.е. запустить через комманд. строку: с:\1.mdb /decompile), а затем откомпилировать и сохранить все модули.
Иногда такую же проблему можно решить, если сжать БД. Я помню, в 97 Access была ещё опция "восстановить БД". Мне интересно, что же кроется за этими опциями? Что физически происходит во время сжатия и восстановления БД. А то в своё время "прощёлкал" это, а вот теперь стало интересно:roll:
Перезаписывает всю базу заново.
Вероятно при этой чистке и сжатие, производится досточно полная ревизия (и как следствие натсройка) базы, что позволяет им называть этот пункт - Сжатие и ВОССТАНОВЛЕНИЕ. Действительно после такого восстановление глючную базу можно оживить.
Ну вообщето, пункт - Сжатие и ... по пачпорту предназначен прежде всего для избавления от накопившегося мусора в базе. Все таки файл mdb один, а в нем и таблицы и формы и код хранится. А главное когда вы в базе удаляете таблицу, то она физически никуда не удаляется, просто в название имени базы добавляется слова -"~TMPCLP" и все :). Если посмотреть программно коллекцию CurrentData.AllTables, то запросто увидите ее, а поменяв ей программно название, опять вытащите на свет божий. И для того чтобы очистить базу от такого мусора, надо периодически делать - "Сжатие и восcтановление". База будет меньше, а данные в ней упорядочены и она будет пошустрее обрабатывать информацию.
Вероятно при этой чистке и сжатие, производится досточно полная ревизия (и как следствие натсройка) базы, что позволяет им называть этот пункт - Сжатие и ВОССТАНОВЛЕНИЕ. Действительно после такого восстановление глючную базу можно оживить.
А можно ли каим-бо то ни было образом программно отлавливать запуск этой опции? Тоесть, написать макрос, который перед сжатием будет куда-либо сейвить удалённые объекты базы?
И, кстати, знаю, слышал, что можно программно инициировать сжатие БД, но как это сделать, не подскажите?
А можно ли каим-бо то ни было образом программно отлавливать запуск этой опции? Тоесть, написать макрос, который перед сжатием будет куда-либо сейвить удалённые объекты базы?
И, кстати, знаю, слышал, что можно программно инициировать сжатие БД, но как это сделать, не подскажите?
Народ! Господа! Товарищи!
Я сума сойду!
*.mdb файл стал регулярно умирать!!!
Причём исправить его можно только одним способом: коды всех модулей кое-как (примерно с 10 попытки - в остальных БД просто виснет ьез сообщений) копирую в текстовый файл. Затем создаю новую БД, куда импортирую из мёртвой все формы, запросы, ну и другие объекты (кроме модулей). Затем создаю в новой БД модкли. Сохраняю. Закрываю. Затем вновь открываю и переношу код из текстового файла в модули. Выставляю свойства. Сохраняю. Закрываю. После этого 2-5 раз всё работает. Затем история повторяется. Умирание БД проявляется в том, что при запуске кода на исполнение всё виснет и вываливается с ошибкой обращения к области памяти. Сжатие БД не помогает!!!
Извините, если я достал уже вас своими вопросами по БД, но для меня это ужас. Каждые 2 часа приходится прерывать работу и мучатся с БД!
С других машин при работе с этим файлом по сети та же самая проблема.
Я бы его сюда выложил, но сами понимаете, никак не могу по понятным причинам.
Заранее всем спасибо!
С уважением,
М.Шатуров.
На счет программного сжатие. Вот тут все на эту тематику: http://www.sql.ru/faq/faq_topic.aspx?fid=155
На счет базы. Что за версия Access?
Так часто умирать она не должна. Поставь сервиспаки и последний MDAC, может у тебя падает из-за уже пофиксенного бага... в любом случае, хуже не будет
На счет сейвов - зачем сохранять то что уже удалено...!?, для сохранения важной инфы надо использовать резервое копирование.
На счет программного сжатие. Вот тут все на эту тематику: http://www.sql.ru/faq/faq_topic.aspx?fid=155
На счет базы. Что за версия Access?
Так часто умирать она не должна. Поставь сервиспаки и последний MDAC, может у тебя падает из-за уже пофиксенного бага... в любом случае, хуже не будет
Спасибо за ссылку :)!
Сейфить попробовать хочу истинно из спортивного интереса.:)
А вот насчёт гибели БД...
Access 2000 (9 версия 4 версия ядра (Jet)), сервиспаки все стоят, а вот насчёт MDAC не знаю
:( .
И всё равно мрёт, зараза...:{
Спасибо за ссылку :)!
Сейфить попробовать хочу истинно из спортивного интереса.:)
А вот насчёт гибели БД...
Access 2000 (9 версия 4 версия ядра (Jet)), сервиспаки все стоят, а вот насчёт MDAC не знаю
:( .
И всё равно мрёт, зараза...:{
Для Jet сейчас уже есть 7 сервиспак, версия файла msjet40.dll - 4.00.7328.0
Ну и конечно надо попытаться опеределить момент падения базы, из-за чего происходит зависание, работает ли она по сети (база Access очень требовательна к настройкам сети). И не совсем понятна, как она себя ведет после зависание: запускается или нет, и что при этом пишет.