>>Думаю пример будет очень полезен многим!

arcdate    otype    amount    saldo 01.01.2009    Приход    100.00:    100 02.01.2009            100 03.01.2009    Расход    40.00:    60 04.01.2009            60 05.01.2009    Расход    15.00:    45 06.01.2009            45

возможно как то так

SELECT календарь.arcdate, [главная книга].otype, [главная книга].amount, (select sum(nz(a.otype*a.amount,0)) from [главная книга] as a where a.odate<=[календарь].arcdate) AS saldo FROM календарь LEFT JOIN [главная книга] ON календарь.arcdate = [главная книга].odate ORDER BY календарь.arcdate, [главная книга].otype DESC;

но много ньюансов

Explorer
Если бы задача была так тривиальна, как в моем примере, тогда да. Но он сильно упрощен.
На самом деле расчетных полей много и все они намного сложнее расчитываются. При этом необходимо именно создание новой таблицы, а не запрос, который будет выполняться при каждом обращении, а база будет сильно тупить.
Если конкретно, то это кредитный калькулятор, который на основе кучи начальных условий рассчитает график погашения тела кредита и начисления процентов. Сумма с нарастанием из моего примера - это задолженность по кредиту.
Но самое главное - заполнить таблицу датами. Если исходная таблица содержит 2 записи с датами 01.01.09 и 31.12.09, то в конечной таблице должно быть 365 записей: 01.01.09, 02.01.09, 03.01.09 и т.д. + прочие поля заполненные по разным правилам.
Мне главное понять алгоритм реализации, с остальным разберусь.
Давайте все же попробуем сделать. Еще раз спасибо!

кстати есть два типа погашения - аннуитетный(равными частями) и классический... + с возможностями досрочного погашения или нет и т.д.

а есть еще кредитные линии, есть кредитные линии с ограничениями по траншам, а еще супсидирование...

[добивает Эксплорера]
да это не страшно :)) т.к. начисление будет считаццо по траншам :))

з.ы. а почему "суп"сидирование? скоро обед? :)

та не... какое прощение? :)) я ж тебя знаю!

я думаю, что если вы задаете ТАКИЕ вопросы дл яТАКОЙ задачи, то вам лучше нанять в реале более продвинутого программиста или обратиться в службу ИТ

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

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

это хорошее, протое и распространенное решение. оно часто помогает упростить приложениеи ускорить обработку данных

кроме того помогающее расширить функционал - в таблице "календарь" можно хранить сведения о рабочих праздничных выходных днях, сезонных акциях, гибких тарифных ставках и т.п.

Кредитный калькулятор - куда уж проще! Как Силblч сказал, два типа, т.е. всего две формулы. Поиск по инету Вам в помощь. А написать процедуру на VBA для расчёта в цикле Вам сможет и школьник.
О каких таких ещё 365 датах между первым января и тридцать первым декабря речь? Что это за кредит такой, что за него каждый день платить надо?! Не, нам таких кредитов не надо, а калькуляторов и подавно. Ну, это шутка... ;-)
Уж не помню, как я реализовал свой калькулятор (посмотрел, вспомнил: открыл набор записей на таблице, в цикле добавил сколько чего надо с расчётом по формуле и ву-а-ля), только он считает ипотеку за... в общем, нажал кнопку и вот вам табличка с 240(!) записями, т.е. ежемесячные платежи. Ну, для домашнего использования большего не требуется. Или надо? Если надо, скажите, добавлю, может быть.
Так что, господа, не горячитесь. Создать таблицу с помощью VBA - это Вам тоже в поиск, т.к. я способов знаю, наверное, два, так что на память не помню (давно не создавал, а если понадобится, то подключу в ссылках библиотеку ADOX, там всё почти по-английский написано).
Про вспомогательную таблицу с календарём можно вопрос? Сколько в ней должно примерно храниться дат и за какой период от текущей (я так думаю, и в прошлое, и в будущее)? Это для общего развития, так сказать, сам то я банковскими системами не занимался.