|
|
|
|
DateAdd('m', -2, Date())))
|
А как правильно написать, чтобы задать интервал в 1.5 месяца
чё прям так и писать
DateAdd('m', -1.5 Date())))
|
| |
|
| |
|
|
|
| формального интервала в полтора месяца не существует, соответсвенно его не может существовать и в БД в любом виде
(хотя бы потому, что в некоторых месяцах нечетное количество дней)
если нужен такой интервал - указывай в днях (45 дней например) | |
|
| |
|
|
|
| спасибо!!!
Стало быть лучше так:
DateAdd('d', -45, Date())))"
|
| |
|
| |
|
|
|
|
не уверен, если только интервал не указан явно в днях (45 дней)
"полтора месяца" неформализованный период - ИМХО лучше отказаться от такого просторечного определения | |
|
| |
|
|
|
| Эт вот из-за чего.....
Данные из таблицы, старше 45 дней - что ы убирать автоматом.....................
поле проверки - дата 09.02.2010 | |
|
| |
|
|
|
| зависит от объема данных и от характера выборки.
в принципе для аналитики, например, логичнее было бы брать за последние 2 месяца - можно приводить и сравнивать результаты (по отношению к предыдущему периоду)
если аналитика не нужна а нужно только подрезать выборку "вглубь" - 45 дней нормальный общепринятый диапазон (можно брать фиксированный степ в глубину 15 дней: 15-30-45-60<?>; далее переходить на календарные месяцы) | |
|
| |
|
|
|
| Спасибо!
Было 2 месяца....
Проболтался заказчику - тот говорит - один месяц и баста
но один месяц - ежедневного обрубания - это фиговато, потому как только перевалило за 31 прежних данных нет....
выбрал компромиссссссссссссссс | |
|
| |
|
|
|
| измени интервал - не 1,5 месяца, а 6 недель - вот тебе и полтора месяца | |
|
| |
|
|
|
| 6 недель тоже неформализованный период если чо
хуже чем 45 дней ИМХО | |
|
| |
|
|
|
| неделя - это внутренний отчетный период у многих организаций, так что это более подходит к данной ситуации, тем более что можно брать поллные недели от текущей | |
|
| |
|
|
|
|
неделя - это внутренний отчетный период у многих организаций
|
да и это нормально
а шесть недель это вообще не период : | |
|
| |
|
|
|
|
| и вместо DateAdd заюзай DateDiff
для этих целей лучше подходит | |
|
| |
|
|
|
| Да ?!
GLB_CONNECTION.Execute "DELETE USERS_TRANSACTIONS_TBL.*, USERS_TRANSACTIONS_TBL.DATE_RECORDS " _
& " From USERS_TRANSACTIONS_TBL " _
& " Where (((USERS_TRANSACTIONS_TBL.DATE_RECORDS) <= DateAdd('d', -45, Date())))"
|
| |
|
| |
|
|
|
| а тут вообще лучше заюзать between :) наверное и/или просто Date()-45
хотя :))) - дело вскуса и общего стиля
Where USERS_TRANSACTIONS_TBL.DATE_RECORDS - 46 < Date()
насет битвин это я погорячился :))) | |
|
| |
|
|
|
| Хорошо - тада оставлям как есть | |
|
| |
|
|
|
| Where USERS_TRANSACTIONS_TBL.DATE_RECORDS - 46 < Date()
Так вычисление:
USERS_TRANSACTIONS_TBL.DATE_RECORDS - 46
будет для каждой записи.
А так:
Where USERS_TRANSACTIONS_TBL.DATE_RECORDS < Date()-45
вычисление Date()-45 только один раз для всех записей.
зы. Если не ошибаюсь. | |
|
| |
|
|
|
| Наверно.... | |
|
| |
|
|
|
| <<SELECT FROM>> WHERE TRANSACTION_DATE NOT IN (<<SELECT>> TRANSACTION_DATE <<FROM>> WHERE TRANSACTION_DATE BETWEEN Date()-45 AND Date())
а вообще какой смысл дропать устаревшие данные ежедневно? | |
|
| |
|
|
|
|
USERS_TRANSACTIONS_TBL.DATE_RECORDS
|
Блин, ну до чего-же нечитабельная конструкция, во всяком случае для меня. | |
|
| |
|
|
|
| нормально - нужно только привыкнуть | |
|
| |
|
|
|
| Да я вот как-то к Гетц-евскому стилю привык.
Читабельней, когда инструкции языка в верхнем регистре, а остальное в нижнем.
Имхо. | |
|
| |
|
|
|
| а я уже отвык ;)
собственно и начинал не с него :) | |
|
| |
|