сервере?
select * from sys.syslanguages where "name" = @@language
тут есть dateformat, но там просто dmy, а мне надо тот формат, что используется в селекте когда он выбирает значения. суть в том, что хочу это использовать на поле datetimeoffset, но без милисекунд и таймзоны
А зачем? Почему не работать с iso format?
отформатировать руками в нужный формат я могу. но хочется чтобы настройки юзера перенимались автоматом.
Работая с iso 8601 вы страхуете себя от необходимости адаптации к локальным настройкам. Меньше кода - меньше проблем
мне надо это для значения затем в пдф. преобразовывать дату можно либо сразу в запросе, либо дополнительный код при формировании пдф. то есть адаптация нужна в любом случае
Вы уверены, что вам для pdf нужна локаль соединения к серверу? Это какая-то очень странная архитектура, мягко говоря Это вообще не на уровне запроса нужно делать
слушайте, я могу решить проблему на разных этапах, разными средствами и т п. я задал конкретный вопрос по скл серверу, как по одному из вариантов. если нет способа решить скл сервером, то ок, решу на следующем уровне
Как вариант - выдернуть любую дату и посмотреть в каком виде возвращает 🤪 Например к запросу SELECT login_time FROM sys.dm_exec_sessions WHERE session_id = @@spid прицепить допустим регулярные выражения и case
Ребята вам предлагают оставить работу с форматом отображения для клиентского приложения. Мне как администратору глубоко исключительно совершенно наплевать на то как вы форматирует дату в клиентском приложении, если могу - ограничиваю права и возможности пользователя заниматься любым форматированием и конвертацией данных на стороне SQL Server. Потому - не нужно форматировать данные на стороне сервера, стоимость операции слишком высока для сервера баз данных
я спросил "как сделать", мне отвечают "не делайте так". но: а) я не спрашивал как не делать, я и сам могу выбрать способ, но варианты интересно иметь; б) ну нельзя так нельзя, принимается. очередная зарубка на транзакт-скл
ну вот у меня основной формат даты -- немецкий. то есть сегодня 12.06.2023, а не 06/12/23 и не 2023-06-12.
универсальное решение предполагает перебор всех возможных культур нормального api работы с культурами в t-sql нет захардкодить варианты для десятка основных рынков можно, безусловно но опять же остаётся вопрос в том, зачем этим заниматься
Вопрос был задан КАК. Я и отвечаю, а не спрашиваю ЗАЧЕМ?🤪
ну вы фактически говорите, что надо написать руками код форматирования под конкретную локаль это очень условное "как" в контексте вопроса про универсальное решение ) так-то частное решение - задача для школьника
Нет. Вопрос такой: ппл, подскажите. где найти формат даты для дефолтного языка на сервере?
Обсуждают сегодня