S.G.Фактически, прочитать их вы не можете, так что фактически их там нет.

я понял что вы очень умны, еще с первой фразы не по делу.

StanislawKp.s. Вот с таким вот чужим ПО приходится работать.Можно почитать информацию про это ПО, будет легче.[/quot]

Можно даже с оплаченным саппортом в онлайне через teamviewer на это дело грустно мастурбировать смотреть.

Dimitry SibiryakovStanislawKоднако при добавлении записи в таблицу, запись создается как если бы я
эту таблицу не чистил.
Что ты под этим имеешь в виду и как именно это выяснил?

у записи есть много полей. id, subj, date create, date modify, date start, date end, comment, moderator и т.д.

я с помощью "чудопрограммы" (TW) создаю новую запись.
я заполняю только поле subj.
инкрементально даётся следующий свободный ID,
date create устанавливается в текущий timestamp.

заглядываем в запись - и видим заполнены ВСЕ поля.

шизеем.
смотрим на
date modify - март 2010 год
date start - март 2010 год
date end - июнь 2010 год
comment - десяток комментов от сотрудников
moderator - человек уволенный в 2011.


смотрим по ID в бэкапе сделанном до чистки таблиц - всё 1:1.
разумеется различается поле date create и author.

все остальное удивительно совпадает.

Ованес СусанянStanislawKразмер базы до изменений 8306 мегабайт.
Средствами IBExpert .
выбрал базу. нашел таблицу. (таблиц нуждающихся в чистке несколько, все и почистил)
нажал F9 - Show Data.
в открывшемся окошке
Table -> Empty Table.
Commit transaction.

размер 8306 мегабайт.

сделал бэкап
размер 5649 мегабайт.

восстановил из бэкапа.
размер 7538 мегабайт.Почему цифры разные, если размер - якобы "прежний" ?

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

авторхочется наглядно увидеть что мусор убранЕсли вам надо оценить, сколько мусора в базе, юзайте (но при ресторе, ес-сно, его уже не будет)[/quot]

что до, что после, gstat -r показывает одну строку с подстрокой "version". (versions нету.)
ODS version 11.2

kdvStanislawKмысль у меня такая - в базе лежат записи помеченные на удаление, но фактически не удаленные.
мысль неправильная. Потому что ты никак не можешь прочитать
а) http://www.ibase.ru/devinfo/mga.htm - про версионность
б) http://www.ibase.ru/devinfo/gbak.htm - про бэкап
во втором документе есть текст


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

kdvStanislawK,

вы лучше указанные статьи почитайте. И поставьте ibtm , после чего сможете разработчикам вашего ПО отправить статистику (включая данные, собранные gstat -r в критические моменты). Кроме того, нужно быть немного администратором, чтобы определить, что тормоза вызваны именно накоплением "мусора" в БД, а не плохой производительностью диска, или еще чего-то.

СОВСЕМ ОТЛИЧНО!

при чем тут "ТОРМОЗА" ?

m7m
И авторы что говорят по этому поводу???

Как всегда: руками разводят, пучат глаза, говорят "это не мы", "так не может быть".

GallemarСтоп,увидел. Это kdv тебя смутил. Твоя проблема в чем? При добавление данных в БД вылезают левые данные?

именно так.

левые данные.
которые формально удалены.

S.G.StanislawKпропущено...
Как всегда: руками разводят, пучат глаза, говорят "это не мы", "так не может быть".Этого действительно не может быть, а вот почему оно произошло, именно они и должны сказать, вообще-то.
Почему не предположить, что дело не в сервере, а в программе? Вы ведь через нее вводите данные?

программа откуда эти данные достает? в астрале хранит?

ведь сто процентное соответствие по ID, той удаленной записи в таблице.

Dimitry SibiryakovS.G.а вот почему оно произошло, именно они и должны сказать, вообще-то.
Выдвигаю гипотезу: информация в БД хранится в нескольких таблицах, не связанных внешними
ключами. Шаловливые ручки аффтара "почистили" мастер-таблицу, а прочие не заметили.
Разработчики приложения для генерации первичного ключа используют max(id)+1 в результате
чего новая "пустая" запись заняла место старой и к ней автоматически привязалась
дополнительная информация от старой. Вуаля, приехали. Вывод: нефиг грязными лапками лазить
в базу.

"Я идиот" - это была первая версия. :)

Перед чисткой базы мы обратились в саппорт. там долго думали и предложили этот способ.

Внезапно, через несколько дней, проявилось.

Трижды перепроверил. Увы. Нет. Я не идиот.

Опять обратились в саппорт, говорят что все правильно. очищены все связанные с этим таблицы.

GallemarStanislawKпропущено...
левые данные.
которые формально удалены.

Если их нет - таки да, id генерируется на клиенте.
Потом смотришь внешние ключи и зависимости этой таблицы. Если их нет.... ну что,тогда печально.
p.s если нет знаний по РСУБД лучше обратится в платный саппорт.

Именно после платного саппорта я и пришел сюда. Советоваться с гуру.