Доступ TimeZoneInfo с сервера SQL 2005
Речь идет не о инъекции, а о свойствах класса.
class Controller @Inject()(thing: Something) { ... }
Он объявляет параметр конструктора. Вы можете использовать thing в теле класса.
class Controller @Inject()(val thing: Something) { ... }
Создает thing геттер. Таким образом, его можно использовать позже как:
class Controller @Inject()(val thing: Something) { ... }
val c1 = new Controller('Something')
c1.thing \\ here is `Something`
Вот хорошая нить об этом: По умолчанию для параметров конструктора scala установлено значение private val?
5 ответов
Я не знаю, можно ли получить доступ к классу TimeZoneInfo от SQL, но он обычно полагал, что хорошая практика придерживается UTC в базе данных с клиентом, делающим перевод в местное время.
Так каждый раз, когда Вы пишете в базу данных, Вы переводите с местного времени в UTC, каждый раз, когда Вы читаете из базы данных, Вы переводите из UTC в местное время.
Править: Из того, что я понимаю проблемы, решение, которое я все еще рекомендовал бы:
1) Сохраните даты в UTC в базе данных. 2) Вычислите местное время в клиенте.
2 может быть сделан различными способами. Рекомендуемый путь состоит в том, чтобы установить DateTimeMode на Локальный (или UTC) в классе DataColumn (*). При необходимости в отчете в местное время используйте Локальный при необходимости в нем в UTC используйте UTC.
(*) Обратите внимание на то, что существуют проблемы с разработчиком в Visual Studio, видят сообщение в блоге: http://bethmassi.blogspot.com/2006/01/serializing-data-across-time-zones-in.html, отчет об ошибках: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=96118
Я столкнулся с этой той же проблемой, потому что я хотел преобразовать между локальным и UTC в запросе, который использовался путем создания отчетов о сервисах. Я прошел то, что, кажется, та же точная борьба, Вы доводите это до конца. Мое решение...
Я начал писать автономное приложение, которое прошло TimeZoneInfo, возражают и записал записи в таблицу TimeZoneInfo в моей базе данных. Я сохранил все смещения (включая смещения перехода на летнее время) в течение каждого года между годом запуска и годом конца (они были аргументами автономному приложению).
От этой таблицы я затем смог создать некоторые функции sql, которые возьмут дату в UTC или локальный и часовой пояс, использовать справочную таблицу TimeZoneInfo, чтобы получить правильное смещение в течение правильного времени года и часового пояса, и возвратить дату и время, преобразованную в UTC или локальную.
К сожалению, я все еще еще не был сделан. Я должен был создать функцию CLR, которая возвратила текущий часовой пояс системы, пользующейся библиотекой, которая БЫЛА безопасна для SQL Server (в отличие от объекта TimeZoneInfo). У меня нет доступа к моему коду в данный момент, но я полагаю, что использовал объект TimeZone.
http://msdn.microsoft.com/en-us/library/system.timezone_members.aspx
Подводя итоги, у меня была функция CLR, которая возвратила часовой пояс системы, приложение, которое произвело часовой пояс, ищет таблицу с DLS определенная информация для диапазона лет. Я завершил все это хранимой процедурой, которая взяла в часовом поясе и дате для преобразования и ее работа красиво с тех пор.
Я понимаю, что это - ОГРОМНАЯ работа вокруг, чтобы сделать что-то, что казалось довольно простым, но это сделало задание безопасным способом.
Мы искали это некоторое время, но не смогли найти хороший способ сделать это. Я думаю, что это было в списке вещей, которые будут добавлены в SQL 2008, если я помню от рассмотрения его некоторое время назад.
Вы читали эту статью на Channel9? Кажется, делает то, что вы ищете, в функции CLR ... хотя я не думаю, что вы получите ВСЕ те полезности, к которым хотите получить доступ ... но это только начало.
http: // channel9.msdn.com/playground/Sandbox/139123/
Проблема, о которой упоминается на одном из плакатов в этом потоке, заключается в том, что это небезопасная сборка из-за p / invoke.
Вот решение:
- Создайте хранимую процедуру CLR или UDF, который охватывает функциональность класса TimeZoneInfo. Следуйте этому руководству: http://www.codeproject.com/KB/cs/CLR_Stored_Procedure.aspx
- TimeZoneInfo требует .NET 3.5. Однако System.Core v3.5 не пройдет проверку в Sql Server 2005. Поэтому вам нужно выполнить CREATE ASSEMBLY для System.Core. См. Подробности: http: //weblogs.asp.net / paulomorgado / archive / 2009/06/13 / plays-with-sql-server-clr-integration-part-iv-deploying-to-sql-server-2005.aspx
Обратите внимание, что вам необходимо зарегистрировать System. Ядро как НЕБЕЗОПАСНОЕ ... так что у вас, администратор баз данных, могут быть проблемы с ним.
Более того, даже если вы выполняли развертывание на Sql Server 2008 (который включает .NET 3.5), ваша настраиваемая сборка должна быть НЕБЕЗОПАСНОЙ, поскольку в ней используются небезопасные методы из TimeZoneInfo: http: // social.msdn.microsoft.com/Forums/en/sqlnetfx/thread/d0515862-eb87-4a13-bab4-0e343983823a
Я попробовал это и получил сообщение о MayLeakOnAbort.
Если НЕБЕЗОПАСНОСТЬ подходит для вашей среды, вы должны суметь это сделать.