Отсутствуют миллисекунды при вставке даты и времени в sql

Я использую определяемый пользователем параметр таблицы для массовой вставки, я создаю определяемую пользователем таблицу, а имя столбца - ModifiedDate в типе данных для даты и времени.

когда я передаю значение в sql, оно будет вставлено нормально, но пропущено значение миллисекунд, тогда как я могу установить это

Моя пользовательская таблица

CREATE TYPE [dbo].[Test] AS TABLE(
[ModifiedDate] [datetime] NOT NULL,
)

My Sp 

ALTER PROCEDURE [dbo].[CP_UpdateData]
-- Add the parameters for the stored procedure here
 @Test Test Readonly,

  INSERT into Test(ModifiedDate)
       Values(ModifiedDate);

но здесь в моем значении даты и времени отсутствует миллисекунда, не могли бы вы помочь с любым предложением для решения этой проблемы

в коде С#

using (var cmd = new SqlCommand())
{
    cmd.CommandText = "CP_UpdateData";
    cmd.Connection = con;
    cmd.CommandType = CommandType.StoredProcedure;
    cmd.Parameters.Add("Test", SqlDbType.Structured).Value = ConvertToDataTable(list);                       
    con.Open();
    var dataReader = await cmd.ExecuteReaderAsync();
}

public DataTable ConvertToDataTableCampaingList(List<Test> list)
{
    var dataTable = new DataTable();

    if (list != null && list.Count > 0)
    {
     dataTable.Columns.Add("ModifiedDate", Type.GetType("System.DateTime"));
     foreach (var data in list)
        {
        var dataRow = dataTable.NewRow();
        dataRow["ModifiedDate"] = data.ModifiedDate;
         dataTable.Rows.Add(dataRow);
        }
    }
    return dataTable;
}

c# sql-server stored-procedures datetime table-valued-parameters
person Manikandan    schedule 29.06.2016    source источник
comment
Я надеюсь, что это не будет вашим первым сообщением, пожалуйста, соблюдайте правильное форматирование при публикации.   -  person sujith karivelil    schedule 29.06.2016
comment
примечание: наилучшая точность типа данных datetime сервера sql составляет 3 миллисекунды. Если вам нужна точность в миллисекундах, вы должны использовать тип данных Time или DateTime2.   -  person Zohar Peled    schedule 29.06.2016
comment
@Zohar, DATETIME по-прежнему возвращает миллисекунды, поэтому DATETIME2 не решит проблему, поскольку ошибки вызывает его компилятор (C#). По определению, VAR в C# — это локальная переменная с неявным типом. var (справочник по C#)   -  person clifton_h    schedule 29.06.2016
comment
Мне достаточно 3 миллисекунд, но в моем случае всегда 000, это моя проблема   -  person Manikandan    schedule 29.06.2016
comment
Да неужели? Из простого поиска в Google DATETIME не имеет неявного формата, так что это может быть виновником здесь. В сочетании с рендерингом вашего компилятора по умолчанию DATETIME. user2380844 ССЫЛКА имеет аналогичный вопрос, где ответ заключался в том, чтобы явно перевести DATETIME в string (что, кстати, вы делаете и в SQL).   -  person clifton_h    schedule 29.06.2016
comment
@clifton_h нет проблем, когда он преобразуется в var, но в моей базе данных он имеет тип данных даты и времени, поэтому мне нужно отправить это в дату и время в таблице, определяемой пользователем, но он пропускает миллисекунды :(   -  person Manikandan    schedule 29.06.2016
comment
Ладно, телега впереди лошади. Откуда берутся значения DATETIME? Ваша БД или программа на C#? Что происходит, когда вы сначала переводите его в строку напрямую, как описано в ссылке? Если вы все еще получаете TRUNCATION значений, проверьте upstring в своем коде.   -  person clifton_h    schedule 29.06.2016
comment
Когда я конвертирую var date = (DateTime.Parse(datetime.ToString(yyyy-MM-dd HH:mm:ss.fff))); он возвращает правильные миллисекунды   -  person Manikandan    schedule 29.06.2016
comment
Давайте продолжим обсуждение в чате.   -  person clifton_h    schedule 29.06.2016
comment
@clifton_h: Я знаю, я только указал, что его точность ограничена 3 миллисекундами. вот почему это было примечание. Я даже не пытался ответить на вопрос.   -  person Zohar Peled    schedule 29.06.2016
comment
Я пытался воспроизвести вашу проблему, но не смог. Я получал миллисекунды каждый раз. Мой код С# был точно таким же, как ваш, за исключением того, что я использовал DateTime.Now в качестве значения для вставки в dataRow. Возможно, data.ModifiedDate уже имеет миллисекунды, установленные на 0?   -  person Zohar Peled    schedule 29.06.2016
comment
@Manikandan, пожалуйста, упростите код и включите код, который фактически генерирует дату. Этот код уже делает некоторые действительно странные вещи, например, использует Type.GetType вместо typeof(DateTime). Он также использует ConvertToDataTable, но вы публикуете другой метод. Код хранимой процедуры тоже не компилируется - нельзя написать VALUES(@Test ModifiedDate). Возможно, у вас есть еще одна опечатка, которая удаляет миллисекунды   -  person Panagiotis Kanavos    schedule 29.06.2016
comment
@PanagiotisKanavos VALUES(ModifiedDate) только я использовал по ошибке, я разместил VALUES(@Test ModifiedDate), typeof(Datetime) также не будет работать   -  person Manikandan    schedule 29.06.2016
comment
@ZoharPeled я всегда получаю 000 миллисекунд, что моя проблема, в таблице запись выглядит так: 2016-06-28 12:53:20.000   -  person Manikandan    schedule 29.06.2016
comment
Я понимаю проблему, но не могу ее воспроизвести. Кстати, ваш оператор вставки должен выглядеть так: INSERT INTO ZZZ_TEMP_TABLE (ModifiedDate) SELECT ModifiedDate FROM @Test   -  person Zohar Peled    schedule 29.06.2016

Ответы (1)


arrow_upward
1
arrow_downward

Ответ находится в обсуждении CHAT ROOM, я опубликую его здесь: проблема заключается в неявных преобразованиях и в том, как каждый компилятор обрабатывает данные. DATETIME по умолчанию не имеет определенного FORMAT, поэтому SQL неявно преобразует данные.

Таким образом, проблема заключается в том, что когда вы сохраняете его в таблице, поскольку форматирование по умолчанию является проблемой CREATE TABLE #Example2 (TIMES DATETIME NOT NULL) INSERT INTO #Example2 (TIMES) VALUES (CONVERT (DATETIME, GETDATE(), 9)) , ( CAST(GETDATE() AS VARCHAR(20)) ) Обратите внимание, как значение по умолчанию в простой строке на самом деле отбрасывает миллисекунды, поскольку ее формат неверен.

Обратите внимание, что решение было explicitly определяющим формат:

  • Маникандан написал:
    #P4#

Преобразование DATETIME в строку делает его переносимым и в типе данных, который не будет TRUNCATE данных. Однако используйте правильный CONVERT (тип данных, выражение, стиль), если вы обеспечиваете точность.

  • Маникандан написал:
    #P6# 
    DECLARE @TEMp TABLE 
( 
ModifiedDate  varchar(50) 
) 

declare @timestring varchar(50) 

set @timestring = '2016-06-28 12:53:20.850' 

Insert into @TEMp(ModifiedDate) 
values(@timestring) 

Insert into @TEMP_Result(ModifiedDate) 
select Convert(datetime, ModifiedDate) from @TEMp 


select * from @TEMP_Result

МОРАЛЬ: ОСТЕРЕГАЙТЕСЬ НЕЯВНЫХ ПРЕОБРАЗОВАНИЙ

  • Implicit преобразования являются догадками и определяются компилятором. Они ненадежны, как показывает этот случай.

  • CAST не является явным преобразованием и может возвращать неправильный формат. Используйте CONVERT в SQL, чтобы избежать неявных преобразований.

  • Хранение DATETIME в строке делает ее переносимой, позволяет избежать TRUNCATION данных и легко конвертируется в правильный формат в SQL.
person clifton_h    schedule 29.06.2016