Я делаю это так
(Date_Encode(EXTRACT(YEAR FROM :CURRDATE),
EXTRACT(MONTH FROM Contr_BD),
EXTRACT(DAY FROM Contr_BD)) between cast(:CURRDATE as date) and :CURRDATE+:iDay)

в свое время понадобилось не извлекать, а собирать дату "Date_Encode". (чет не понял до сих пор нет встроенной возможности EXTRACT же есть. И засада если строку кастить такого плана будет ошибка.)

Смысл прост зачем что то сложно было вычислять. Берем текущий год, а месяц и день дня рождения.
При переводе 2001, 2, 29 функция сервера ФБ возвращает нам 01.03.2001. Так что когда нет 29 февраля то празднуем 01 марта и это логично т.к. с начало года именно столько дней. Но на вкус и цвет товарищей нет ;)

хотя дурдом для того кто родился после 29 февраля по идее надо праздновать в день года, а не в день месяца )


function __Date_Encode(Year: Word = 0; Month: Word = 0; Day: Word = 0;
Hour: Word = 0; Min: Word = 0; Sec: Word = 0): PISC_QUAD;
var
tm_date: tm;
begin
with tm_date do begin
tm_year := Year-1900;
tm_mon := Month-1;
tm_mday := Day;
tm_sec := Sec;
tm_min := Min;
tm_hour := Hour;
tm_isdst := 0;
end;
Result := ib_util_malloc(SizeOf(TISC_QUAD));
__isc_encode_date(@tm_date, Result);
end;

{DECLARE EXTERNAL FUNCTION Date_Encode
INTEGER, INTEGER, INTEGER
RETURNS DATE FREE_IT
ENTRY_POINT "fn_Date_Encode" MODULE_NAME "B_UDF2.DLL";}
function fn_Date_Encode(var Year, Month, Day: Cardinal): PISC_QUAD; cdecl; export;
begin
Result := __Date_Encode(Year, Month, Day);
end;

wadmanЕще вариант с днем в году, ему все равно на проблему 29-го февраля кмк. :)

Не совсем если 29 в феврале то все что было после съедет в том году в котором будет 28. Приходилось и такое использовать, но тогда надо 2 параметра использовать день в году + дельта для года. Но дельту проставляем только при ориентировании после 29 числа, и логика по году на вкус. дельта либо 0 либо 1 или 0 и -1 зависит от того как от какого года отталкиваешься.

Если сильно на производительность влияет то за основу храним всегда как будто 29 дней есть всегда в году и дельту. А при поиске учитываем что надо найти день равный как будто в году с 29 днями. Так для сравнения надо будет использовать только 1 поле ;) А дельту пригодится когда ни будь для других задач

wadmanЕвгений БолтикНе совсем если 29 в феврале то все что было после съедет в том году в котором будет 28.
Ошибаешься. Примеры (меняется только дата):



Вот и не ошибаюсь т.к. твои примеры говорят о дополнительной логике. Я же говорю о возможности исключить вычисление сравнивать с еще и дельтой. Но поразмышляв немного (пока копировались 20ГБ баз) самый простой вариант это хранить 2 поля дней для вис и не вис годов. Только в этом случае мы избавимся от вычислений ;) В этом случае на 100% будет задействован индекс без всякого перебора данных.

wadmanЕвгений БолтикВот и не ошибаюсь т.к. твои примеры говорят о дополнительной логике.
Программирование - это в принципе логика. Рабочий вариант выложен 14792661 и твое возражение мне совсем не понятно. Индексы задействованы.

wadmanЕще вариант с днем в году, ему все равно на проблему 29-го февраля кмк. :)


Я имел ввиду что просто по дню не получится придется логику городить. ;)
И просто намекнул, что либо упростить через дельту или как в последнем посте по 2 полям по ситуации с каким годом сравнивает человек.
Я считаю лучше сразу написать один раз быстро работающий вариант и везде его применять чем тащить логику по всей программе с граблями вдруг чего не дописал :)
Если же разово и неважна производительность. Я привел тоже пример выше как сделал я много...много лет назад и было в то время по барабану там данных мало. Но сейчас я бы сделал это по другому, если бы стояла задача.

PS В тему вник просто захотелось мозги размять после нудной переписки всего механизма репликации. А в спорах мысли новые иногда приходят. К примеру если интересно напиши мне условие как ты проверяешь вхождение одного периода в другой.
с D11 по D12 и с D21 по D22

wadmanЕвгений БолтикЯ имел ввиду что просто по дню не получится придется логику городить. ;)
Вкратце вердикт: минусов не видишь, просто свой вариант нахваливаешь. :)

Здрасте вам не нахваливаю говорю доводы почему сделал бы так. Не мне решать что ты будешь или спросивший внедрять у себя. Для конечного пользователя лишь бы работало. Причем я посмотрел бы на того кто будет разбирать код с километровой конструкцией, что про меня или про тебя он скажет.
Я в спое время был не прав что написал так с "__isc_encode_date". По той причине кто же догадается что системная функция ФБ при 29 февраля вернет 1 марта и поэтому все работает ;) Я просто увидел тему подумал у меня же та же фигня надо перепроверить. Перепроверил перекрестился что все работает и снова к своим делам. Но на заметку взял что надо переписать это место т.к. у одного 2 или 3 клиентов там данные прибывают ежемесячно. Всему свое время