компутерный юмор

[jes 0]

Забавно то что тэг code оформлен как <?php

Не политкоректно

[Guest]

http://aforce.livejournal.com/1063148.html

[Archer 1623]

А говорите откуда анекдоты берутся.

Вот такой перл нахожу переделывая работу после ДАТАБАЗОВЕГО ЭКСПЕРТА.

        INSERT 
        Core.Data_DetailCRMCaseInvoicingChangeByMonth
        (
            [Service],
            Country,
            CRMCaseID,
            CurrentInvoicingType,
            LastCheckDate,
            PLastCheckDate,
            PCreatedDate
        )
        VALUES
        (
            @Service,
            @Country,
            @CRMCase,
            @InvoicingType,
            dbo.fn_DateToInt(GETDATE()),
            GETDATE(),
            GETDATE()        
        )

 

Даже непосвященные увидят, что процесс для трёх совершенно разных дат вставляет дату выполнения процедуры.Правда, в одном месте заботливо переформатированную в ИНТ.(Зачем - никто не знает , даже автор.)

 

Ничего странного в этом коде не вижу. Представь себе, что тебе надо внести первую запись. Это значит, что CreateDate и LastCheckDate равны. Названия полей в базе говорят о типе - префикс "P" для поля типа datetime, и, скорее всего, integer или number для поля LastCheckDate. Вполне возможно, что из этой таблицы читает еще какой-то процесс, который не умеет конвертировать datetime в integer или наоборот. Поэтому для него в базе два разных типа с одним и тем же. А вот то, что автор сам не знает (не помнит) причину - уже ахтунг

[jes 0]

Это значит, что CreateDate и LastCheckDate равны.

Они могут быть не равны ( даже если с учетом до секунд )

и даже

LastCheckDate != PLastCheckDate

[Archer 1623]

Они могут быть не равны ( даже если с учетом до секунд )

и даже

LastCheckDate != PLastCheckDate

 

Во-первых - читайте внимательно про "первую запись".

Во-вторых - это было предположение, основанное на доступной информации. Равно и не равно в реальности может быть всё что угодно...

[jes 0]

Какая разница первая или вторая запись . GETDATE при последующем вызове может вернуть уже другую дату. Хотя я могу ошибаться, но нутром чую что так.

[Archer 1623]

Какая разница первая или вторая запись . GETDATE при последующем вызове может вернуть уже другую дату. Хотя я могу ошибаться, но нутром чую что так.

 

Хорошо, объясняю на пальцах Есть функция, которая СОЗДАЕТ запись. Т.е. делает INSERT. Есть другая функция, которая делает UPDATE записи (поля LastCheckDate).

 

Так вот мы спорим про первую функцию.

 

P.S. AgentXXX, похоже, пошел делать глубокий reverse engineering...

[jes 0]

Флуд не по теме. Просто для ясности.

Смотри, сделал ты инсерт а там LastCheckDate и РLastCheckDate разные, то есть разные процессы ( в твоем предположении ) найдут разные записи.

Да и вааще, дата модификации раньше чем дата создания.

[Archer 1623]

Флуд не по теме. Просто для ясности.

Смотри, сделал ты инсерт а там LastCheckDate и РLastCheckDate разные, то есть разные процессы ( в твоем предположении ) найдут разные записи.

Да и вааще, дата модификации раньше чем дата создания.

 

Тот INSERT, что показал Agent, делает CreateDate, LastCheckDate и PLastCheckDate одинаковыми (разный тип не в счет), и равными системному времени на момент выполнения INSERT. Никакого криминала я в этом не вижу, могут существовать задачи, для которых именно такой вариант есть логичный и правильный. Возможные задачи уже были озвучены.

 

О том, что с этими данными будет дальше, нет смысла дискутировать, мы этого не знаем.

[alp 0]

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

 

Это не так. На самом деле будет лишь один вызов getdate. Причем это должно быть так даже если вставляется одним инсертром большое количество записей продолжительное время. Время будет одно.

В приведенном коде в отвязке от логики приложения не вижу ничего криминального.

[Alex Debian 0]

[gri4 0]

Угу, alp прав. Ща проверил на 20000 inserted rows. Один вызов GETDATE()

[badun 0]

Вот и спалились все ДБАшники )

Открываем филиал sql.ru

[jes 0]

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

[AgentXXX 1]

Значится когда надо будет в датовый склад складывать данные за 5 лет с датой выполнения процедуры аж три раза, я буду знать куда обратиться.

Приходишь на форум и все здесь.

Послушать вас, так несколько миллионов записей с 3 х гетдатом в одной таблице имеют очень большой смысл.

Особенно когда надо (сгруппироровать/выбрать/вернуть в аппликацию) данные по дням, месяцам, неделям, кварталам, годам.

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

Я уже не говорю о том, что в селекте юзать функцию для преобразования датового типа - не есть гуд.

Даже НЕэксперт по базам напишет

cast( convert( char(8), data, 112) as int)

могут существовать задачи, для которых именно такой вариант есть логичный и правильный

Арчер, приведи пример.Ты меня так заинтриговал, что я весь в интересе.

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