Размер фаила БД

Здравствуйте,
проблема вот в чем,после удаления записи в таблице access объем размера фаила базы не изменяется,вопрос почему?
программа в архиве прикреплена к теме

Вложения

АБДД.rar (3.84 Мб, 25 просмотров)

0

Когда мы удаляем запись, то мы ее после не видим, а она остается в БД как бы в "невидимом" для глаз пользователя состоянии. Для этого необходимо выполнить процедуру, подобную той, что в MS Access выполняется так (на примере 2003):
сервис/служебные программы/сжать и восстановить БД
После этой процедуры БД теряет в весе, за счет стирания ранее удаленных пользователем записей
Надеюсь понятно изложил ))

1

проблема вот в чем,после удаления записи в таблице access объем размера фаила базы не изменяется,вопрос почему

..............

Миниатюры

 

1

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

Что касается увеличения размера файла БД - то это общепринятая для скл-серверов технология резервирования дискового пространства для обеспечения стабильной производительности при "плановом" росте объемов хранимой информации.
При желании можно подробно почитать об этом в той же википедии например.

1

зачем же делать сжатие после каждого удаления записи?
можно сделать отдельную кнопку с процедурой сжатия базы данных

0

Не надо делать никаких кнопок ! И вообще нельзя никаких АДМИНИСТРАТИВНЫХ функций по обслуживанию БД впихивать в клиентское приложение !!! Это же ведь элементарные меры хотя бы для обеспечения безопастности потери данных при работе в многопользовательскитм приложении.
Сжатие как и резервирование, восстановление, "ремонт" и т.д. относятся к сервисной службе и должны выполняться квалифицированным специалистом и в строго определенном прядке.

И вообще совет Вам: обращайте внимание на размер файла БД акцеса только тогда, когда он превысит гиг. До тех же пор просто забудьте про эту "проблему", просто уяснив для себя, что на производительность работы это никак не влияет !

Добавлено через 37 секунд
безопастности от потери данных

1

гиг она точно превысит
и что мне тогда делать?

0

гиг она точно превысит и что мне тогда делать?

https://www.cyberforum.ru/atta... 1319600359

0

Сообщение от Aizent и что мне тогда делать?

Немедленно забыть про акцесс, выбросить его в мусорку и пользовать более серьезные клиент - серверные СУБД

0

Основания для такого заявления имеются ? В студию !

Когда Ваша база "дорастет" до такких объемов, очень возможно, что Вы будете уже умудренным опытом "базовиком" и "перевезти" Вашу базу на мсскл (как наиболее родную акцесу) для Вас будет делом пустяшным

0

Правда что, если есть предпосылки для такого роста БД. Стоит отказаться от Access.

Сообщение от MsGuns Когда Ваша база "дорастет" до такких объемов, очень возможно, что Вы будете уже умудренным опытом "базовиком" и "перевезти" Вашу базу на мсскл (как наиболее родную акцесу) для Вас будет делом пустяшным

Опять же, мы не знаем, может человек там рипы фильмов хранить будет. :-)
Ну, или вообще файлы. Мы не знаем.
Ну, а сжатие, да, в клиента выносить кнопку не стоит. А вот процедурку и вызов из консоли с параметрами для сжатия сделать можно.
Т.е. при необходимости можно будет сделать сжатие не делая никаких манипуляций в Access.
Ну либо разделить интерфейс.
На админский и пользовательский.
И соответственно поделить функционал.

0

Ага, решать проблема "фильмотеки" посредствои акцеса - это типа возить на стройку бетон стаканами.

0

Ну про фильмы я юморил.
Но человек там картинки хранить собирается.
А может и еще чего. В общем я не так уж и ошибся.
Ну что сказать.
Стоит пересмотреть архитектуру программы в целом.
Например как в базе храним информацию о файле.
Ссылку на файл.
А файл в файловом хранилище.
В общем иначе строить программу.

0

в БД будут загружаться документы юридического отдела предприятия,а документооборот там довольно таки большой я думаю)

Добавлено через 3 минуты
а насчет хранить ссылки на фаил в БД,я так уже и сделал
и интерфейс разделил

0

Ну вот а теперь еще подумайте на тему почему у вас для автоматизации отдела используется Access. У вас один человек в отделе?
А если более, то им базу перекладывать с одного компа на другой. Или по очереди ходить как по нужде?
Ну а далее.
На самом деле есть схожая задача. Но пока в стадии сбора мыслей и взгляда на реализуемое в целом.
Потому что я не очень приемлю локальные решения к которым потом надо лепить еще что-то.
Так что можно попробовать вместе подумать. Может в итоге получится более интересный проект.
Правда я смотрю в сторону веб интерфейса. И с делфи здесь связываться не хочу.

0

Одно из двух.

1. Вы - юрист или сотрудник (рук-ль) юротдела, желающий бумажные горы "засунуть" в компьютер. Да так, чтобы можно было быстро найти (в т.ч. по содержимому, т.н. контекстный поиск). К тому же надо чтобы ВСЕ документы лежали в одном хранилище, а не по столам сотрудников.
Вам нужно просто посмотреть готовые решения, коих нынче предостаточно. Для начала можно просто нагуглить, тупо набрав в поисковике фразу "система документооборота"

2. Вы - программист, которому поручили (тот же юрист) чего-нибудь наваять в духе электронного документооборота. Тогда акцес+сжатые документы в BLOB-полях. Приложение должно работать в режиме "только чтение". Для дозаписи/замены документов надо написать еще одно, "админское" приложение, с которым будет работать понятно кто. Остальные юристы могут искать и выбирать в базе любые документы (разрешенные им разумеется), распаковывать на свои лок.диски и работать с ними. Но вот класть их на место старых - уволльте - только через админа
Это - реальный проект, который Вы вполне можете реализовать за достаточно короткий срок имея только делфу.

0

Ну на гора могу толкнуть вот сюда.Alfresco.
Я смотрю в ее сторону но пока с юристами не сели и не обсудили хватит ли данного функционала.
Или нужно доставать напильник.
И да MsGuns, мы опять же не знаем ECM нужна или это просто электронный архив.
И кстати вот с этим не совсем согласен.

Сообщение от MsGuns Это - реальный проект, который Вы вполне можете реализовать за достаточно короткий срок имея только делфу.

Ибо ECM система подразумевает хранение версионности документа а это довольно таки сложный момент с точки зрения хранения информации.
Я поэтому пока в состоянии сбора мыслей и взгляда на реализуемое в целом.
А не приступаю к реализации.
Ибо мне кажется что каждый документ в этом варианте должен представляться как некоторый контейнер. Внутри которого лежат все его версии с момента зачатия документа т.е. регистрации в системе и да родов т.е. попадания в архив.

0

rdama
зачем же перекладывать базу?
программа будет залита на один компьютер да,но доступ к ней с других комп. будет по сетке
насчет веб тож думал,но решил все-таки на делфе
MsGuns
не то и не другое
все намного проще))) я студент,это будет моей курсовой
идейку подкинул сотрудник одного предприятия,т.е. я ее делаю и на курсовую и для юр.отдела этого предприятия

Добавлено через 9 минут
MsGuns,
кстати насчет сжатия документов может подскажете как реализовать?
в БД будут фаилы не более 1 мб,ограничение я сделал
а если объем фаила более 1 мб хочу их сжимать(уменьшать)
прогуглил,нашел что-то типа
но чтот не выходит(я на правильном пути вообще?)))

0

Не морочьтесь, вполне достаточно использовать ахиватор xxxZip, xxxRar, xxx7z etc
Для надежности можно либо включить его в инсталяшку либо как требование к конфигурации ПК
Вызывать используя обычный ShellExecute

Добавлено через 10 минут
Чтобы не быть голословным...
Есть такая область, как контрольно-измерительные системы. Программа "снимает" показания датчика и записывает их в таблицу. Так вот, если показание N точно такое же, как N-1, но его НЕОБХОДИМО записать. Да, в таблице будут 2 (а может быть и больше) одинаковых записей. НО ТАК НАДО !
Вы скажете, надо добавить в таблицу UID
А зачем ?
Таблица обрабатывается, например, каждый час и РЕЗУЛЬТИРУЮЩАЯ гистограмма записывается в другую таблицу, после чего ЧИСТИТСЯ !
Вопрос: с какой радости тут UID, который будет абсолютно лишним, т.к. не используется совершенно

Добавлено через 5 минут
Ну это, батенька, уже Вас понесло
Не надо придумывать черных кошек в черной комнате

0

Сообщение от MsGuns Ну это, батенька, уже Вас понесло

Ну отчего же.
Как раз таки если внутри системы предусматривать цепочки согласования документа., то вопрос версионости как раз и возникает.
Если у документ в процессе согласования проходит через несколько отделов. Каждый из отделов вносит свои изменения в него. И комментирует их в сопроводительной информации к нему.
А документ исходный мы не можем заменить. Потому что это первичная болванка.
Вот так и возникает версионость файла. Т.е на каждой стадии согласования возникает новый документ и необходимо хранить и его и предыдущие версии.
После прохода до стадии Согласован.Завершен документ уходит в архив.
Вот как-то так должно все это работать.
А задача которая решается ТС это автоматизация ведения реестра договоров. И до кучи его линковка с файлами. Но не документооборот.

PS. Опять же я сразу сказал что у меня схожая задача, но не такая. Более глобальная. И реестр договоров это мелочь.
И да MsGuns, прав когда сказал

Это - реальный проект, который Вы вполне можете реализовать за достаточно короткий срок имея только делфу.

Ваш проект именно такой.

0