ИМХО, проще всего написать в общем модуле функцию типа:

Public Function GetMaxDate(Date1,Date2,Date3,Date4) Dim d    d = Date1  If Date2 > NZ(d, 0) Then d = Date2  If Date3 > NZ(d, 0) Then d = Date3  If Date4 > NZ(d, 0) Then d = Date4    GetMaxDate = d End Function

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

банальные функции access без всяких там модулей

В конструкторе запроса (имена полей - Date1, Date2, Date3, Date4):

Макс: IIF([Date4]>NZ([Date1];0) And [Date4]>NZ([Date2];0) And [Date4]>NZ([Date3];0); [Date4]; IIF([Date3]>NZ([Date1];0) And [Date3]>NZ([Date2];0); [Date3]; IIF([Date2]>NZ([Date1];0); [Date2]; [Date1])))

Или я неправильно понял вопрос? Может вам нужно Min и Max даты в каждом столбце? Тогда почему вы получаете "1" или "-1" (покажите свой запрос)? А если я понял правильно, то причем здесь Sum?

в моем профиле написано "ламер"

И вас это устраивает? Может пора осваивать VBA?

если написать функцию, то она будет естесно на VBA, но она очень медленная получиться ...
сколько строчек у Вас в таблице бывает??? и сколько столбцов максимум бывает???
=============================
придётся сночала бегать по всем столбцам и смотреть свойство столбца дата или нет потом пробежать по всему столбцу, либо запросом определить Max(value) и запомнить в переменную, затем след. столбец, затем из двух выбрать большую и так далее......
а имеются столбики, которые с датой но их смотреть не надо? Если да, то автоматизировать не выходит......... хотя это имхо или ихмо.......

столбцов с датами пока 5, смотреть их нужно все. Строчек порядка 2000. Структура БД дибильная, но ничего поделать не могу, есть форма.... Появиться столбцы с датами могут, т. к. допродать можем и в следующем месяце.

Появиться столбцы с датами могут, т. к. допродать можем и в следующем месяце.

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

Очень жаль, что не могу скинуть файл.. Все дело в том, что не я пытаюсь сдеать из аксеса ексэль, а требования "начальства", которая просит соблюдать форму и при этом хочет порой от аксеса всего, что душа попросит (как сейчас, получается..). Я бы давно все в экселе сделал и выводилось бы всё куда проще. Ну да ладно, это все лирика. Постараюсь объяснить, может, это поможет..

Купили мы, например, 50 ценных бумаг А и 30 ценных бумаг Б 1.03.09, но продали мы их не в один день, а частями, скажем, бумаги А: 05.04.09 - 20 штук, 10.04.09 - 17 штук и 15.04.09 - 13 штук. А бымаги б мы продали, скажем в 2 дня: 09.04.09 -15 штук и 18.04.09 - 15 штук. Так вот есть такая несоклько необходимых формул доходности, и одна из них требует вычета из последней (!!!) даты продажи дату покупки. В случае с бумагами А - это 15.04, а с бумагами Б - 18.04. А теперь (внимание), самый дибилизм! выглядит в аксессе это все следующим образом
дата дата дата
продажи 1 продажи 2 продажи 3
А 05.04 10.04 15.04
Б 09.04 18.04

То есть, если бы столбцы, грубо говоря, были по датам, то мы бы тупо взяли последнюю. Но идет в реестре все именно так, как описано выше...

Я так понимаю, мне за 2 дня надо VBA освоить? ))

...Основная форма - даты. Подчиненная - продажи...

Дружище Гоблин,
Нет такой сущности "Дата" ни здесь, ни в каких других БД!!!
"Дата" это одна из возможных характеристик других сущностей.

НЕ НАДО выделять под не нее ни отдельных таблиц, ни форм.

В данном случае, она должна быть характеристикой сущности "Транзакция" (операция с ЦБ).

pistachio,
"Выпрямить" имеющуюся таблицу продаж к нормальному виду можно запросами.
Если сейчас в таблице 5 полей с датами, значит это можно сделать 5 запросами.

Вам ответ на вопрос был дан в 15:28.
Если вы не в состоянии его понять, откройте учебник, полистайте.

автор: Анатолий (Киев) (22.07.2009 в 15:28)

количество столбцов будет увеличиваться, когда уже не хватит места ) пока, грубо говоря, бумаги А мы продали 5 раз - это максимум. Не мсключено, что му будеи продавать бумаги С раз 10, при этом они будут занимать каждый овый столбец.

Не очень понял первый вариант с "групповичком", но мне чертовски понравился второй, особенно, если этот один столбец можно как-нибудь сделать не в ручную, то есть, не копируя-вставляя все 8 штук в один.

про маразм - согласен, но ничего не поделаешь...

Да, то, что вы прислали, очень похоже на истину, только непонятно, как вы сделали это "поле 1". Судя потому, что режим конструтора не открывается, то как-то хитро )

Писачо. Там запрос на объединение стоит. Открывается только в режиме sql.
Просто иными словами. Делаешь 8 запросов как Лукас говорил. 1 - на поле1, Второй - на поле 2 3 - на поле 3 и т.д. Затем каждый из этих запросов открываешь в режиме sql. После берешь запрос1, копируешь содержимое, переходишь в содержимое запроса 2, стираешь сзади ; и вместо нее пишешь слово union, после чего вставляешь в содержимое буфера обмена. Затем полученное копируешь и переходишь к запросу 3. Позади стираешь ; и вставляя union вставляешь содержимое буфера...

Можно и проще в данном случае. делаешь запрос на выборку на поле1, копируешь его в режиме sql, тут же стирая ; ставишь union и вставляешь из обменника. Там только скорректируй поле2 и далее в том же духе.

Прислушайся к Анатолию (Киев) и Лукасу. Это программеры. Я же любитель кроссвордов акса.

Мне ещё рано спасибо говорить. Я с Вами не закончил. Требования начальства - это конечно, закон. Но нельзя воспринимать эти требования буквально. Данные должны быть организованы так, чтобы работать с ними было удобно. Структура данных создаётся один раз, потом её не меняют (случаи, когда меняют, не рассматриваем ;-)) Поэтому, если на каждую новую продажу - суть операцию - менять структуру таблицы - так делать не надо. Потому что при этом Вам придётся поменять все формулы, все процедуры ввода, вывода и проч.
Рассмотрим Ваши бумаги. Вы их покупаете и продаёте, хотите это дело учитывать. Начальство обычно хочет красивый отчёт в виде нескольких столбцов, где по строке показана история бумаг одного типа, но отчёт - это последнее, что я делаю при создании системы. Сначала структура. Итак, бумаги - это вещь, следовательно будет одна таблица, в которой будем хранить описание этих вещей. Бумаги бывают одинаковых типов - тогда ещё одна таблица, в которой будут храниться типы бумаг. Операции купли/продажи - это может быть одна таблица или две по одной на покупку и продажу. Столбцы таблиц - это свойства того, что в них будет храниться. Так, например, покупка имеет свойства: дата покупки, что купили, сколько и по какой цене, у кого и т.д. и т.п.
В общем копайте в сторону реляционных баз данных.
Когда со структурой разберётесь, переходите к интерфейсу. Вот тогда потребуются подчинённые формы и запросы (поменьше бы всяких IIF, лучше вообще без них).
Если начальству надо было вчера, посылайте его на... поиски готовой программы за XXXX у.е., где X (икс) - это целое больше нуля. Хочет сэкономить, придётся пока пользоваться счётами или Excel.
Удачи!

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

У вас "начальство" - дама? Да уж...

Да еще и блондинка.
этак на каждую продажу новую таблицу заводить придется.

Я бы уволился, пока жив.

Но тогда их, по идее надо связывать по названию эмитента..

"Правильной дорогой идёте, товарисч!"

Спасибо за примерчик. Раньше бы такой. Вечная проблема с подчиненной формой - не хочет вводить новую запись без привязки к таблице основной формы. Приходилось хоть в одну строку таблицу создавать, что бы хоть как-то с места сдвинуть.
Бум разбираться.

Даты - это календарь.
А я примерчик скачал.