|
Проблема рост размера базы, НЕ сжатие!
|
|||
---|---|---|---|
#18+
Здравствуйте! Прошу извинить за флуд, но проще спросить у знающих. Вопрос по возможности НЕувеличения размера базы, именно отстутствия роста размера, а не возможностей сжатия из FAQ, про которые всё известно (и применяется мной в разных вариантах). Вообще возможно ли такое? Простой пример: база Акс2003, в нее импортируется таблица (в моем случае dbf), потом производятся внутренние обработки и так каждый день. НО таблица большая и если два раза подряд импортнуть без сжатия, то возникает проблема переполнения базы (превышение макс.размера 2145 Мб) при обновлении внешней таблицы. Импортируемая таблица всегда практически одинакового размера. Попробовал и удаление ее и последующий импорт и очистку таблицы и ее заполнение из прилинкованной - толку нет, размер базы mdb всё равно пропорционально растет если базу предварительно не сжать. Конечно можно попробовать прерывать процесс после очистки, или удаления таблицы командой сжатия, но тогда прерывается сам внутренний процесс. Можно конечно подумать над фичей, чтобы разделить процесс на "До" и "После", но мне кажется как-то это кривовато. Есть мнения, или я задал глупый вопрос? Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2018, 14:33 |
|
Проблема рост размера базы, НЕ сжатие!
|
|||
---|---|---|---|
#18+
Есть мнение. Организовать импорт программно. Создаём новую БД, создаём в ней связанную таблицу, импортим в неё данные, обрабатываем, сохраняя данные в текущей, отсоединяем таблицу, удаляем новую БД. Есть и другое мнение. Ставим любой локальный SQL-сервер (MS SQL CE, MySQL, Firebird, etc.), создаём там прилинкованную таблицу нужной структуры, импорт выполняем в неё. Есть и третье мнение. Просто в свойствах БД устанавливаем "Сжимать при выходе". ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2018, 15:11 |
|
Проблема рост размера базы, НЕ сжатие!
|
|||
---|---|---|---|
#18+
AkinaЕсть мнение. Организовать импорт программно. Создаём новую БД, создаём в ней связанную таблицу, импортим в неё данные, обрабатываем, сохраняя данные в текущей, отсоединяем таблицу, удаляем новую БД. неоднократно применяла этот вариант ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2018, 15:27 |
|
Проблема рост размера базы, НЕ сжатие!
|
|||
---|---|---|---|
#18+
AkinaЕсть мнение. Организовать импорт программно. Создаём новую БД, создаём в ней связанную таблицу, импортим в неё данные, обрабатываем, сохраняя данные в текущей, отсоединяем таблицу, удаляем новую БД. Объективно правильный вариант, но таким же образом можно просто прилинковаться к исходному файлу без создания промежуточной базы и потом удалить файл. Но мне нужно именно импортировать таблцу в защищенную базу mde, чтобы потом использовать эту таблицу в других задачах. AkinaЕсть и другое мнение. Ставим любой локальный SQL-сервер (MS SQL CE, MySQL, Firebird, etc.), создаём там прилинкованную таблицу нужной структуры, импорт выполняем в неё. Это сложнее, чем заданный вопрос))) и в разрезе задач ну никак не подходит! AkinaЕсть и третье мнение. Просто в свойствах БД устанавливаем "Сжимать при выходе". Да это, то понятно, я специально в теме указал "НЕсжатие", чтобы конкретизировать. У меня база ежедневно обновляемая, к концу месяца достигает существенного размера, что и мешает ее корректной работе с очередным импортом исполняемой таблицы. Это не критично т.к. задействованы механизмы проверки размера и сжатия. Интересен вопрос скорее в академических целях. Почему если я очистил таблицу, то ее очередное заполнение данными не рекалькулирует доступный объём базы. Как-то так. Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
29.04.2018, 09:40 |
|
Проблема рост размера базы, НЕ сжатие!
|
|||
---|---|---|---|
#18+
Я могу разделить свою процедуру на две секции:. Первая удаляет (ну или очищает внутренню таблицу), потом отправка команды сжатия в cmd (ну или созданием батника с его запуском, что собственно практически одно и то же) и во второй секции уже продолжать импорт таблицы не переживая за размер. Но здесь уже придется передавать запуск второй секции внешнему управляющему процессу, который собственно и не хочется задействовать, чтобв не усложнять весь процесс. Поэтому и вопрос. Если без сжатия никак, то тему закрыли. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.04.2018, 09:52 |
|
Проблема рост размера базы, НЕ сжатие!
|
|||
---|---|---|---|
#18+
kulib, как вариант(однажды применяла) --есть база интерфейса --есть база справочников --и на каждый год ОПЕРАТИВНАЯ база tabXXXX при начале работы --сообщается год --меняется текст запроса на select * from otab in "d:\temp\tab" & GOD & ".ACCDB" --далее основной таблицей является этот запрос --- сжатий не делала совсем иногда требовались итоги с нескольких лет, примеяла рабочую табдицу, куда дописывала итоги по годам ... |
|||
:
Нравится:
Не нравится:
|
|||
29.04.2018, 10:15 |
|
Проблема рост размера базы, НЕ сжатие!
|
|||
---|---|---|---|
#18+
ПЕНСИОНЕРКА, Да, наверное этот метод, его производную мне и придется применять в своей задаче, раз никак по другому нельзя "впихнуть" всё в одну базу, а так хотелось. Уж очень не хочется предоставлять пользователю многофайловость для работы в локальном режиме. Так-то одна база и если она есть, значит есть, нет- значит нет. А то потом лишние обращения типа "а у меня не работает" и только из-за того что нет каких-то доп.баз ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2018, 10:52 |
|
Проблема рост размера базы, НЕ сжатие!
|
|||
---|---|---|---|
#18+
kulibПЕНСИОНЕРКА, раз никак по другому нельзя "впихнуть" всё в одну базу, а так хотелось...... Почему нельзя ? Очень даже можно . Немного потрудитесь , и будет Вам счастье. 21377367 -вариант(мнение) Nr.2. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2018, 12:27 |
|
|
start [/forum/topic.php?desktop=1&fid=45&tid=1611475]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
48ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 154ms |
0 / 0 |