| 
			
			 | 
		#1 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
			
			
			Дата и время в Axapta
			 
			
			Возможно кому-нибудь пригодится данная конструкция. 
		
		
		
		
		
		
		
	Стояла следующая проблема: Т.к. Axapta не умеет хранить в одном поле дату и время (например 11.11.2009 22:02:33), принято хранить эту информацию в двух отдельных полях (типы полей Date и Int). Это затрудняет поиск данных по периоду. Я решил данную проблему следующим образом (пример для Oracle): TO_DATE(TO_CHAR(T.DATE + (T.TIME/86400), 'DD.MM.YYYY HH24:MI:SS'), 'DD.MM.YYYY HH24:MI:SS') BETWEEN TO_DATE(TO_CHAR(TO_DATE('01.01.2010', 'DD.MM.YYYY') + (60692/86400), 'DD.MM.YYYY HH24:MI:SS'), 'DD.MM.YYYY HH24:MI:SS') AND TO_DATE(TO_CHAR(TO_DATE('22.02.2010', 'DD.MM.YYYY') + (43200/86400), 'DD.MM.YYYY HH24:MI:SS'), 'DD.MM.YYYY HH24:MI:SS')  | 
| 
	
 | 
| 
			
			 | 
		#2 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
Это справедливо только для более старых версий АХ, до появления типа utcDateTime  | 
| 
	
 | 
| 
			
			 | 
		#3 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Работаю на 4-ке, данного типа данных utcDateTime  у меня нет 
		
		
		
		
		
		
		
	 
		 | 
| 
	
 | 
| 
			
			 | 
		#4 | 
| 
			
			 NavAx 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Есть. 
		
		
		
		
		
		
			К примеру, таблица SysClientSessions. Поле Login_date там именно такого типа, хотя нигде увидеть это из Аксапты невозможно - только из SQL Studio. Т.е. там не только дата входа хранится, но и время заодно, ибо SQL тип - DateTime. Из-за этого, кстати, запросы типа select clientSessions where clientSessions.Login_date < systemdateget()) могут возвращать немного не то, что хотелось бы. И в Global:: есть функция для работы с такими convertUTCDateToLocalDate, а вот обратной, кстати, нет, что приводит к проблемам с такими запросами. Если интересно - можно еще посмотреть по ссылкам, где эта функция используется. Но вот самому такое поле, думаю, заполнить не выйдет - это поле заполняется самим ядром. 
				__________________ 
		
		
		
		
		
			Жизнь прекрасна! Если, конечно, правильно подобрать антидепрессанты...  
			Последний раз редактировалось Maximin; 11.02.2010 в 12:20.  | 
| 
	
 | 
| 
			
			 | 
		#5 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Это потому что АХ 4 - старая версия  
		
		
		
		
		
		
			
		
		
		
		
	![]() Данный тип был добавлен в АХ 2009  | 
| 
	
 | 
| 
			
			 | 
		#6 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			В AX 2009 как я понимаю данный тип поля уже является стандартным? Т.е. его можно применить для редактирования т.п. 
		
		
		
		
		
		
		
	http://www.axaptapedia.com/UtcDateTime  | 
| 
	
 | 
| 
			
			 | 
		#7 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			Сообщение от nix0root
			 
 
			В AX 2009 как я понимаю данный тип поля уже является стандартным? Т.е. его можно применить для редактирования т.п. 
		
	http://www.axaptapedia.com/UtcDateTime  | 
| 
	
 | 
| 
			
			 | 
		#8 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Жаль что этот тип не откроют в полный доступ в 4-ке, на 2009 мы врятли  будем переходить. Поэтому буду юзать прямые запросы к бд с TO_CHAR и TO_DATE
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#9 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Если не секрет, почему врядли переходить будете?
		 
		
		
		
		
		
		
			
				__________________ 
		
		
		
		
	Ivanhoe as is..  | 
| 
	
 | 
| 
			
			 | 
		#10 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Во первых это дорого нам встанет. 
		
		
		
		
		
		
		
	Во вторых долго. В третьих ловить ошибки потом в теч длительного времени , тк у нас много своих наработок. Ну и самое главное у нас ORACLE )))) а на сколько я знаю 2009 уже никак не поддерживает ORA. Собственно вот почему мы не будем переходить на 2009  
		 | 
| 
	
 | 
| 
			
			 | 
		#11 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			2009 поддерживает ORACLE http://www.microsoft.com/dynamics/en...ents-2009.aspx
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: nix0root (1). | |
| 
			
			 | 
		#12 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Извините конечно, но я так и непонял, что такого делает этот прямой запрос, что нельзя сделать средствами аксапты?  
		
		
		
		
		
		
		
	Вы же вот это хотели получить? Или я что-то не понимаю? Код: ((T.Date > fromDate) || ((T.Date == fromDate) && (T.Time >= fromTime))) && ((T.Date < toDate) || ((T.Date == toDate) && (T.Time <= toTime))) У меня, напротив, встречный вопрос. Учитывая, что Как теперь будут выглядеть запросы, в котроых ограничено должно быть только время, но не число?  | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: belugin (1), Gustav (2). | |
| 
			
			 | 
		#13 | 
| 
			
			 Ищущий знания... 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			Сообщение от S.Kuskov
			 
 
			Извините конечно, но я так и непонял, что такого делает этот прямой запрос, что нельзя сделать средствами аксапты?  
		
	Вы же вот это хотели получить? Или я что-то не понимаю? Код: ((T.Date > fromDate) || ((T.Date == fromDate) && (T.Time >= fromTime))) && ((T.Date < toDate) || ((T.Date == toDate) && (T.Time <= toTime))) ![]() Например, есть таблицы: Table1 с полями: FromDate, FromTime, ToDate, ToTime Table2 с полями: FromDate, FromTime, ToDate, ToTime известно значение Table2, нужно проверить есть ли пересекающиеся во времени строчки в Table1... вот такой случай решается в аксапте геморойно  
		
				__________________ 
		
		
		
		
	"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем  | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: nix0root (1). | |
| 
			
			 | 
		#14 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Ну даже с учетом поддержки 2009-й OR-ы, стоимость и время все равно остаются критичными
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#15 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Про переход и затраты понятно, но вот про возможности..  
		
		
		
		
		
		
			  Пока из своего опыта 2009 намного стабильнее, полноценные 64 бита и т.п., в части функциональности много нового и интересного, в т.ч. локализаторы стараются.В т.ч. дата и время не просто новый тип, он активно участвует в расчетах сроков поставки и проч., есть настройки часовых поясов пользователя. 
				__________________ 
		
		
		
		
	Ivanhoe as is..  | 
| 
	
 | 
| 
			
			 | 
		#16 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			А с какой базой вы работаете если не секрет, и чем пользуетесь для отчетов?
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#17 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
Цитата: 
	
X++: ((T1.fromDate < T2.toDate) || ((T1.fromDate == T2.toDate) && (T1.fromTime <= T2.toTime))) && ((T1.toDate > T2.fromDate) || ((T1.toDate == T2.fromDate) && (T1.toTime >= T2.fromTime))) P.S.: Накатал тут на коленке пару макросов для работы с датами и временем. Может кому пригодится. X++: #localmacro.lessOrEq
    /* (%1) - Date_1 */
    /* (%2) - Time_1 */
    /* (%3) - Date_2 */
    /* (%4) - Time_2 */
    ( ((%1) < (%3)) || ( ((%1) == (%3)) && ((%2) < (%4)) ) )
#endmacro
#localmacro.greatOrEq
    /*(%1) - Date_1 */
    /*(%2) - Time_1 */
    /*(%3) - Date_2 */
    /*(%4) - Time_2 */
    ( ((%1) > (%3)) || ( ((%1) == (%3)) && ((%2) > (%4)) ) )
#endmacro
#localmacro.dt
    /* (%1) - Date */
    /* (%2) - Time */
    %1, %2
#endmacro
#localmacro.between
    /* (%1) - DateFrom */
    /* (%2) - TimeFrom */
    /* (%3) - DateTo   */
    /* (%4) - TimeTo   */
    /* (%5) - Date     */
    /* (%6) - Time     */
    (#greatOrEq(#dt(%5, %6), #dt(%1, %2)) && #lessOrEq(#dt(%5, %6), #dt(%3, %4)))
#endmacro
#localmacro.cross
    /* (%1) - DateFrom_1 */
    /* (%2) - TimeFrom_1 */
    /* (%3) - DateTo_1   */
    /* (%4) - TimeTo_1   */
    /* (%5) - DateFrom_2 */
    /* (%6) - TimeFrom_2 */
    /* (%7) - DateTo_2   */
    /* (%8) - TimeTo_2   */
    (#lessOrEq(#dt(%1, %2), #dt(%7, %8)) && #greatOrEq(#dt(%3, %4), #dt(%5, %6)))
#endmacro | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: nix0root (1). | |
| 
			
			 | 
		#18 | 
| 
			
			 Ищущий знания... 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			Сообщение от S.Kuskov
			 
 
			А неужели преоброзование типов работает быстрее пары лишних сравнений? 
		
	Вообще эта задача ничуть не сложнее предыдущей. В том смысле, что для её решения нужно то же число сравнений. X++: ((T1.fromDate < T2.toDate) || ((T1.fromDate == T2.toDate) && (T1.fromTime <= T2.toTime))) && ((T1.toDate > T2.fromDate) || ((T1.toDate == T2.fromDate) && (T1.toTime >= T2.fromTime))) ![]() согласитесть, что вот так, было бы более прозрачно и понятно: X++: if (T1.FromDateTime <= T2.ToDateTime && T1.ToDateTime >= T2.FromDateTime)
				__________________ 
		
		
		
		
	"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем  | 
| 
	
 | 
| 
			
			 | 
		#19 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
P.S.: А на мой вопрос (Дата и время в Axapta) есть у кого-нибудь ответ?  | 
| 
	
 | 
| 
			
			 | 
		#20 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			Сообщение от S.Kuskov
			 
 
			Согласен. Про это нет и речи. Я, всего лишь, против прямого SQL там, где это не нужно 
		
	P.S.: А на мой вопрос (Дата и время в Axapta) есть у кого-нибудь ответ? Более развернутый ответ: Не помню, надо искать пример и разбираться. Может как-то на досуге...  | 
| 
	
 |