08.12.2005, 17:45 | #1 |
Участник
|
Временные зоны
Приветствую всех,
может кто сталкивался с проблемой локального времени? пример: клиенты сидят в разных часовых поясах, например во Владивостоке и Калининграде. при вставке записи в таблицу, в поля createdTime и createdDate будут вставлены время и дата клиента, а не сервера. таким образом невозможно(очень сложно) отследить когда реально была сделана запись, а в случае с большой разницей во времени и вовсе происходит путанница. Есть ли какие нибудь идеи по этому поводу? |
|
08.12.2005, 20:15 | #2 |
NavAx
|
хм... прикрутить к пользователям часовой пояс и показывать (учитывать) его в нужных местах вместе с полями createdTime и createdDate
__________________
И все они создания природы... |
|
08.12.2005, 20:19 | #3 |
Участник
|
так и сделал, но не хочется помнить постоянно о том, что если появился новый пользователь на определнееые операции, то его добавить к часовому поясу, причем интересы пользователя могут пересекатся, причем на удаленном клиенте может банально стоять неверно часовой пояс
|
|
08.12.2005, 20:22 | #4 |
NavAx
|
хм...
1) сделайте это поле ОБЯЗАТЕЛЬНЫМ при создании юзера 2) Проведите с админом удаленного офиса операцию ППЗ (пинок под зад) 2а) приготовьте скрипты для исправления косяков в случае чего
__________________
И все они создания природы... |
|
08.12.2005, 20:23 | #5 |
Member
|
А еще часть логики может отрабатывать на клиенте, а часть на сервере...
__________________
С уважением, glibs® |
|
08.12.2005, 20:25 | #6 |
NavAx
|
Цитата:
Сообщение от glibs
А еще часть логики может отрабатывать на клиенте, а часть на сервере...
__________________
И все они создания природы... |
|
08.12.2005, 22:44 | #7 |
Участник
|
SBO таскает время с сиквела
ALTER PROCEDURE TmSp_GetServerTime --With Encryption AS declare @date datetime set @date = GETDATE() SELECT CONVERT (int, @date), (DATEPART(hh, @date)*3600) + (DATEPART(mi, @date)*60) + DATEPART(ss, @date) Последний раз редактировалось shuhard; 08.12.2005 в 22:56. |
|
09.12.2005, 10:17 | #8 |
Участник
|
Всем спасибо за участие, видимо решения (как заставить систему жить по системному времени сервера) не существует.
Административные, программные и прочие способы доступны, так и работаем, но хотелось сделать и забыть. Предпочитаю делать системы, не требующие администрирования. |
|
09.12.2005, 10:55 | #9 |
Участник
|
может можно при старте системы как-то перевести время на серверное (спросить время у сервера и установить)? может быть есть способ сделать так, чтобы конкретное приложение жило по указанному времени?
|
|
09.12.2005, 17:28 | #10 |
Member
|
Есть вариант с "закручиванием гаек". Начиная с Windows 2000 prof. при подключении пользователя к домену у него можно отобрать права на изменение системной даты и времени. Можно также каждый раз при загрузке синхронизировать дату и время (например, если ее сменили через COMS Setup). Если у вас удаленный офис, то может существовать разница в минутах, но не в часах или днях.
А вот как бороться с клиент-серверной разницей, а также с самим часовым поясом пока не ясно.
__________________
С уважением, glibs® |
|
09.12.2005, 17:44 | #11 |
Участник
|
спасибо, но это все не то.
мы решили проблему путем программирования аксапты (пришлось помнить у кого какой пояс). а загнать всех можно, куда угодно, можно построить людей, надавать по голове(рукам) линейкой и применить прочие административно-хозяйственные способы, только если человек живет во Владике, то московское время ему не интересно. Вопрос то в том, что если запись создается на сервере (а она создается на сервере всегда) то и отмечать система должна время вставки именно по серверному времени. как вариант - запускать все процедуры на стороне сервера, но это решение одной задачи в ущерб остальным, и приемлемым не является. |
|
12.12.2005, 14:38 | #12 |
Участник
|
Можно на SQL сервер на все таблички прикрутить по паре тригерочков. При синхронизации придется их заново восстанавливать, зато пользователи лишаются возможности безнаказанно "химичить" с системной датой на клиенте.
|
|
12.12.2005, 15:34 | #13 |
Administrator
|
Цитата:
Сообщение от glibs
А еще часть логики может отрабатывать на клиенте, а часть на сервере...
Добавлено: Вы, конечно, будете смеяться, но у меня в createdDate/modifiedDate проставляется дата с сервера (с АОС), а не с клиента. Только что специально проверил. Axapta SP4.
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
12.12.2005, 15:38 | #14 |
Участник
|
точно, только запись формируется иногда на клиенте.
попробуйте насторить на клиенте иное время и разнести журнал ГК (пердварительно включив например на LedgerTrans createdTime и createdDate) 3.0 сп3 |
|
12.12.2005, 15:47 | #15 |
Administrator
|
Цитата:
Сообщение от mit
попробуйте насторить на клиенте иное время и разнести журнал ГК (пердварительно включив например на LedgerTrans createdTime и createdDate)
3.0 сп3
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
12.12.2005, 15:52 | #16 |
Участник
|
может у меня пиратская аксапта
даже не знаю что сказать. но проблема реально существует. имеем трехуровневую конфигурацию, разные временные зоны и разное время. как результат сервер вставляет записи по времени клента |
|
12.12.2005, 16:27 | #17 |
Administrator
|
А версия клиента/сервера у Вас какая?
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
12.12.2005, 16:44 | #18 |
Участник
|
клиент Microsoft Business Solutions-Axapta 3.0 Build #1951.3730/514-193 SP3/OP023-71,
ну а сервер к нему насколько помню только такой же (по протоколу) подходит |
|
|
Похожие темы | ||||
Тема | Ответов | |||
Временные Таблицы и проблемы с ними | 39 | |||
Временные таблицы должны быть вложенными (inner)... | 14 | |||
Временные таблицы | 6 | |||
Временные таблицы | 3 | |||
Временные таблицы в запросе | 4 |
|