Если Время_работы - краткий формат времени не превышает 24 часов, то можно воспользоваться функцией CDbl
SELECT T1.Организация, Sum(CDbl(T1.время_работы)) AS [Sum-время_работы]
FROM T1
GROUP BY T1.Организация

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

Но это не все, для того чтобы теперь показать Sum-время_работы, например в формате ччч:мм нужна будет функция переводящая Double в стринг

Mari.PФункцию написать - можно конечно, вот только как обратиться к этой функции в запросе???

А чего сложного?

Допустим, ф-ия такая:


Твой запрос сохраняем, например в ААА и тогда

FinansСкладывать значения формата "Краткий формат времени" всё равно, что складывать даты: (22-ноя-2004) + (23-ноя-2004). Продолжительность каких-то событий необходимо хранить в единицах (часах, минутах, ..), т.е. в числовом формате.

Формат даты на самом деле и есть числовой формат (Double )

Mari.PСпасибо за помощь, но если время больше 24 часов то запрос вернет ерунду?
Ну почему же ерунду? Он вернет: смешанное число, целая часть которого - количество дней, тк при умножении не 24 - кол-во часов, а дробная часть - это части дня: 1 сек = 1/24/60/60. Отсюда и пляшем!

АлексейКтак не получится?

SELECT T1.Организация, Sum(CDate(T1.время_работы)) AS [Sum-время_работы]
FROM T1
GROUP BY T1.Организация

Получается следующее:
CurrentDb.Execute "create table t (h time)"

CurrentDb.Execute "INSERT INTO t (h) VALUES ( ""12:20"")"
CurrentDb.Execute "INSERT INTO t (h) VALUES ( ""12:20"")"
CurrentDb.Execute "INSERT INTO t (h) VALUES ( ""12:20"")"
CurrentDb.Execute "INSERT INTO t (h) VALUES ( ""12:20"")"
CurrentDb.Execute "INSERT INTO t (h) VALUES ( ""12:20"")"
CurrentDb.Execute "INSERT INTO t (h) VALUES ( ""12:20"")"

SELECT Sum(CDate([h])) AS HH
FROM t;
результат: 3.0833333333333

Применяем мою функцию, получаем
?DoubleToTime(3.0833333333333,0)
74:00

АлексейК

Но часы нужны не от 0 а только остаток, а тогда сложно выходит

Примерно так:

SELECT datediff( "h",0 ,Sum(CDate([h]))) & ":" & format(datediff( "n",datediff( "h",0 ,Sum(CDate([h])))/24 ,Sum(CDate([h]))),"00") as WorkTime
FROM t

Shark
Можно по-подробнее? Какая разница между Date, Currency и Double в этом случае? Если хранить время (чч:мм) в Currency или в каком другом числовом типе (кроме целочисленного), то число в любом случае будет дробным. Так при чем здесь рассуждения про 2+2 = 4?

Думаю, что все это - дело вкуса! Действительно, нет подходящего формата для хранения промежутков времени. Если они (промежутки) гарантированно меньше 24 часов, мне больше нравится хранить их как есть в формате времени.Легче при показе в формах и отчетах. При необходимости проведения над ними арифметических вычеслений, можно пользоваться почти всеми встроенными функциями времени и даты. Неудобства возникают только при превышении в сумме единицы. Но и эта проблема достаточно легко решается при помощи вышеизложенных вычисений или функций.
А при применении типа денег, как то не очень приятно видеть в напрямую открытой таблице символ доллара или фунта или еще какой-нибудь деньги (шекеля к примеру) вместо ожидаемых 00:00

SharkНет, алгоритма у меня нет.
Я думаю, что поле для ввода строки должно быть не свободным, а связанным, те надо добавить строковое поле в табличку. И если не удалось преобразовать его своим кодом в карренси, то ругаться. А если удалось, то преобразовывать карренси самому обратно и переписывать это поле. Тогда кажется будет работать как будто это стандартный формат.

Нет сомнений - логика в рассуждениях Shark есть! С подобными преобразованиями я столкнулся при использовании географических координат. Поскольку такого типа не существует и, более того, его передают в разных форматах (в градусах и частях градусов, в градусах, минутах и частях минуты, в радусах, минутах, секундах и частях секунды, широта и долгота может присутствовать в буквах или выражаться положительным или отрицательным числом; кроме того широты, как известно изеряются до 90 град., а долготы до 180) то нет другого выхода, как хранить каждую координату в двух полях - численном (для поиска на картах) и стринговом (для показа и ввода на экране). Головной боли - более чем предостаточно!
необходимы функции для взаимного перевода форматов - из числового в стринговый и наоборот, не простой функции, проверяющей корректность введенной координаты и проч. Слава богу, что еще не приходится производить суммирования по координатам! Но приходится вычислять расстояния - и это тоже становится не очень просто.
Это все я привел для примера к тому, что предлагает Shark при работе с денежным форматом в применении к промежуткам времени. Я убежден, что в большинстве случаев (те когда промежутки времени не превышают 24 часа) все-же удобнее хранить их (промежутки времени) в формате даты. нет головной боли при вводе-выводе, а при арифметических действиях над ними необходимы просетйшие функции пеобразования в необходимый стринговый формат - и все! В общем-то и в случае промежутков времени больших чем 24 часа рассуждения - те же. Не должно быть проблем. А что касается точности вычислений, то их тоже можно регулировать не сложным образом, например, добавлением 0.5 секунды для вычислений с точностью до секунды.