Братцы, кто нибудь знает как можно увеличить лимит объема mde-файла ?
2 Гб не хватает !

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

дык в том то и дело, что таблица одна.
Если б можно было, как в DBF - базу хранить в одном файле, а индексы - в другом, вопросов бы не было !
Вот такая вот загагулина :(

Кстати, по поводу перехода на SQL - я бы рад. Пусть даже на InterBase (полегше будет), но обстоятельства не позволяют. Тока Аксесс. А иначе - вилы.

2 Geo
Ты понимаешь, там "пейзажи" не имеют понятия - актуален/не актуален.
Я думал о создании архивной таблицы, но тогда не понятно по каким критериям относить запись к архивной. Они ВСЕ актуальны.
Можно конечно попробовать тупо разбить базу пополам, и в запросе делать Union из двух баз. Если другого выхода не найду, сделаю именно так.

2 Geo.
Как я уже сказал, абсолютно все записи являются актуальными. Поэтому всегда приходится делать полный поиск. Сам понимаешь, для поиска по такому объему нужен хотяб минимальный набор индексов. Иначе - труба.
Вот с ними-то и загвоздка. Для нового индекса места нехватает.
Ну чтож... видимо придется делить таблицу на две...
Я просто думал, может каким нибудь хитрым способом в Аксессе можно убрать 2-х гигабайтное ограничение. Или обмануть его как

Ребяты, базу не я проектировал и заливал данными изначально не я.
Мне вот по наследству достался такой вот урод :(
Полей штук 25. Причем почти все символьные (что досадно увеличивает объем)
Индексов - 5, но нужен шестой.
А записей - около 6 млн.
Но, уважаемый, Лох Позорный (извиняй, но ты сам себя так назвал), как нормализовывать базы я и без тебя знаю. И прочие основы проектирования реляционных баз тоже знаю.
База нужна в таком виде, в каком она сейчас есть. Иначе весь софт переписывать, а это ваще - вилы.

2 АлексейК
Мудрую вобщем-то вещь сказал. Я думал над этим.
Т.е. пытался разбить базу вертикально на две составляющих.
При этом нужно в исходной базе завести некое уникальное поле, идентификатор (а таковое сейчас отсутствует, из-за падонков -проектировщиков). Затем часть полей слить в другую таблицу плюс этот же идентификатор, чтоб было с чем Join делать, а затем из исходной таблицы убить эти поля.
Но. Представь, каково 6-и млн записям проставлять ID ? Пробовал создать автоинкрементное поле - ругалась на недопустимое кол-во блокировок. Увеличил этот параметр в реестре. Теперь говорит что нехватает виртуального диска. Вобщем там всё туго :(

2 Нуф-нуф
Ну я вот выше по этому поводу высказался.

> Лох Позорный
Нда... Пробовал я цикл. По самым скромным подсчетам - 10 часов займет.
Через пару часов машина виснет намертво. А узнаю я это просто - TaskManager показывает перегруз процессора, в то время как жесткий диск отдыхает полностью :)
Нет, видимо придется делить таблицу горизонтально.

Сжимал - но она мало сжимается. Я так понял, символьные поля она не особо хочет сжимать.

>Лох Позорный
>Связь между таблицами в разных базах ты не настроишь. Так что Join'ы твои тормозить будут :(

Почему же не настрою ? Я вобще-то так и работаю. Т.е. одну базу беру за основную, и прилинковываю к ней остальные. Причем довольно непростой запрос, с 3-мя Join'ами из разных баз, свистит пулей. Естественно запрос по индексированным полям.

Еще я вот чего не могу понять.
У меня клиентская часть написана на Delphi. Т.е. сам Аксесс мне как таковой не нужен, а нужна база mde. Так вот. При переполнении файла как я понял ругается сам аксесс, т.к. проверяет размер.
А если клиент Delphi, возможно ли такое что я вылезу за эти 2 гб беспрепятственно ?

нда. Значит это сам Jet отслеживает....
Мне вобщем то уже дали добро на нормализацию баз и переписку кода.
Времени вроде дали достаточно.
Но ёлы палы.....
Грусно все это :(
Я вобще-то по ораклу специализируюсь, поэтому не знал раньше такого понятия как "нехватает места в базе" :) А тут вот жисть преподнесла аксесс, и сразу такая вот заморочка.