Однажды наступает момент, когда Акес уже не может справляться с потребностями клиента в полях-со-списками, подчинеными формами, вычисляемыми полями, все более возрастающим объемом данным и т.п. Программа медленно умирает, выход я нашел один - MS SQL. Что сейчас и осваиваю. И чем больше я узнаю, тем мне становиться себя жалче за бесцельно потраченные годы на Акес :(

Если кто-то хочет возразить, что акес прекрасно работает в сети, я спорить не буду. У каждого свои приложения, у каждого разный уровень требований к интерфейсу. ( например, у меня клиент попросил чтобы при вводе оплат всегда показывалась долг клиента (событие ТекущаяЗапись), а потом удивлялся как это стало медленно работать через несколько месяцев, пришлось на расчет кнопку вешать)

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

Можно сделать элементарное сворачивание периодов (выкинуть данные из действующей базы в архив), но тогда возрастет сложность проведения аналитики по всем периодам. Это, наверное, самый оптимальный путь. Но сделать сворачивание данных для уже разработанной системы очень сложно, правда выгода будет заметна сразу для он-лайн ввода и обработки, но будут еще большие тормоза при попытках получать анализы (многочисленные Union,
вычленение данных из разных архивных баз/таблиц и т.п.), хотя и тут есть выход, например, через временные таблицы.

2an

>Формулы лучше вносить в запрос, а в форме выдавать как поля.


Почему-то микрософт считает иначе:

2 Лоху

К сожалению, мой опыт показывает, что основной тормоз это подчиненая форма, условное форматирование, поля со списками. Вычисляемых полей я делаю мало (1 или 2 от силы, все нужные расчеты по нажатию кнопки, например) поэтому мог и не заметить тормоза от них.

2 AItis
>Пришёл к выводу, что всё встаёт на свои места при импорте всех обьектов в новую БД, и ёё перекомпилировании.

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

>А далее проиндексировал все поля используемые в запросах
Новый подход в индексировании?

Или ты имел ввиду все поля исполmзуемые в условиях отбора и установки связей?

2 Лоху
>Вместо импорта можно decompile - восстановить - сжать - скомпилировать. Должно к тому же эфекту приводить.

Неа. Не приведет. Пример: база 19Мб - делаем декопиле-сжать - разме 19 Мб
Импортируем: размер 11 Мб.
Работаем (создаем пару форм, 10 запросов) - размер 30 Мб; сжимаем - размер 19 Мб - импортируем 11 Мб ...

А производительность зависит от множества факторов, один из которых сжатая база.