преобразование данных

Работаю с FireBird. В базе хранятся значения типа time, необходимо посчитать сумму этих значений. Среда разработки, к.т. работает с Firebird (FastReports) не позволяет выполнить преобразование. Поэтому решил написать хранимую процедуру, выполняющую преобразование. Ведь в обычном запросе это невозможно???
Как можно преобразовать Time в Int в хранимой процедуре?
Заранее спасибо.

Ищи тут - на форуме.
Где-то было.

/*Идея там в следующем*/ select sum(t.MyTime - cast('00:00:00' as time) ) from MyTable t /*Или что-то вроде этого.*/

Ага, например: CAST('00:00:00' AS TIME)+SUM("TIME"-CAST('00:00:00' AS TIME))

Осталось только ответить себе на вопрос - а что, собсно, полученная цыфирь будет означать.
______________________________________
Cоздавать БД надо для того чтобы любой человек не знающий SQL мог пользоваться ею.
Не моё. Честно украденный перл.

Ну, цифрь должна означать суммарное время, наговоренное пользователем за период, но только чет запрос неработает, в чем ошибка?

select sum(cast(Таб1.время as integer)), Таб2.номер, Таб2.имя
from Таб1, Таб2
where Таб1.ключ=Таб2.ключ
group by Таб2.номер, Таб2.имя
order by Таб2.номер, Таб2.имя

А слабо найти или написать функцию, возвращающую дельту между двумя концами периода в выбранных единицах?

Posted via ActualForum NNTP Server 1.3

Имееш ввиду StoredProsedur?

Я имею ввиду UDF...
Что-то типа

function DateTimeSpan(FromDate, ToDate: Timespamp; UOM: int): BigInt;

Posted via ActualForum NNTP Server 1.3

grebnev

Ну, цифрь должна означать суммарное время, наговоренное пользователем за период, но только чет запрос неработает, в чем ошибка?

Как известно (если читать доку), тип данных TIME предназначен для хранения не временнЫх интервалов, а точек на временной оси. Вот, скажем, сейчас 20:02. И вчера, что характерно, был такой момент, когда было 20:02. Я тебе больше скажу - даже позавчера тоже было. И, скажем так получилось, что кажен день в одно и то же время кто-то что-то делал. И вот, суммируем три раза по 20:02 в одну посуду. Получаем 60:06. И, что характерно, это, во-первых вовсе не суммарная продолжительность каких то действий, а ХЗЧ. И это ХЗЧ, что не менее характерно, в крынку максимального объему 24 часа ну никак не лезет, хоть задавись. Отсюда морал - врменной интервал, вычисливши, надо укладывать не в TIME, а в какой-нибудь нумерикоподобный тип и пользовать далее в любой мыслимой позе.

длительность событий (интервалы) надо хранить в integer, чтобы над ними можно было производить агрегацию. например, начало разговора - timestamp, а длительность разговора - integer, допустим в секундах.
Это очевидно даже на этапе проектирования БД.