jes 0 Nahlásit příspěvěk Odesláno May 23, 2008 Забавно то что тэг code оформлен как <?php Не политкоректно Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
Guest Nahlásit příspěvěk Odesláno May 23, 2008 http://aforce.livejournal.com/1063148.html Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
Archer 1624 Nahlásit příspěvěk Odesláno May 23, 2008 А говорите откуда анекдоты берутся. Вот такой перл нахожу переделывая работу после ДАТАБАЗОВЕГО ЭКСПЕРТА. 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 или наоборот. Поэтому для него в базе два разных типа с одним и тем же. А вот то, что автор сам не знает (не помнит) причину - уже ахтунг Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
jes 0 Nahlásit příspěvěk Odesláno May 23, 2008 Это значит, что CreateDate и LastCheckDate равны. Они могут быть не равны ( даже если с учетом до секунд ) и даже LastCheckDate != PLastCheckDate Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
Archer 1624 Nahlásit příspěvěk Odesláno May 23, 2008 Они могут быть не равны ( даже если с учетом до секунд ) и даже LastCheckDate != PLastCheckDate Во-первых - читайте внимательно про "первую запись". Во-вторых - это было предположение, основанное на доступной информации. Равно и не равно в реальности может быть всё что угодно... Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
jes 0 Nahlásit příspěvěk Odesláno May 23, 2008 Какая разница первая или вторая запись . GETDATE при последующем вызове может вернуть уже другую дату. Хотя я могу ошибаться, но нутром чую что так. Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
Archer 1624 Nahlásit příspěvěk Odesláno May 23, 2008 Какая разница первая или вторая запись . GETDATE при последующем вызове может вернуть уже другую дату. Хотя я могу ошибаться, но нутром чую что так. Хорошо, объясняю на пальцах Есть функция, которая СОЗДАЕТ запись. Т.е. делает INSERT. Есть другая функция, которая делает UPDATE записи (поля LastCheckDate). Так вот мы спорим про первую функцию. P.S. AgentXXX, похоже, пошел делать глубокий reverse engineering... Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
jes 0 Nahlásit příspěvěk Odesláno May 23, 2008 Флуд не по теме. Просто для ясности. Смотри, сделал ты инсерт а там LastCheckDate и РLastCheckDate разные, то есть разные процессы ( в твоем предположении ) найдут разные записи. Да и вааще, дата модификации раньше чем дата создания. Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
Archer 1624 Nahlásit příspěvěk Odesláno May 23, 2008 Флуд не по теме. Просто для ясности. Смотри, сделал ты инсерт а там LastCheckDate и РLastCheckDate разные, то есть разные процессы ( в твоем предположении ) найдут разные записи. Да и вааще, дата модификации раньше чем дата создания. Тот INSERT, что показал Agent, делает CreateDate, LastCheckDate и PLastCheckDate одинаковыми (разный тип не в счет), и равными системному времени на момент выполнения INSERT. Никакого криминала я в этом не вижу, могут существовать задачи, для которых именно такой вариант есть логичный и правильный. Возможные задачи уже были озвучены. О том, что с этими данными будет дальше, нет смысла дискутировать, мы этого не знаем. Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
alp 0 Nahlásit příspěvěk Odesláno May 23, 2008 GETDATE при последующем вызове может вернуть уже другую дату. Хотя я могу ошибаться, но нутром чую что так. Это не так. На самом деле будет лишь один вызов getdate. Причем это должно быть так даже если вставляется одним инсертром большое количество записей продолжительное время. Время будет одно. В приведенном коде в отвязке от логики приложения не вижу ничего криминального. Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
Alex Debian 0 Nahlásit příspěvěk Odesláno May 23, 2008 Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
gri4 0 Nahlásit příspěvěk Odesláno May 23, 2008 Угу, alp прав. Ща проверил на 20000 inserted rows. Один вызов GETDATE() Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
badun 0 Nahlásit příspěvěk Odesláno May 23, 2008 Вот и спалились все ДБАшники ) Открываем филиал sql.ru Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
jes 0 Nahlásit příspěvěk Odesláno May 23, 2008 Был не прав, но мне простительно, я к ДБ очень далекое имею отношение, я только логически рассуждал Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky
AgentXXX 1 Nahlásit příspěvěk Odesláno May 23, 2008 Значится когда надо будет в датовый склад складывать данные за 5 лет с датой выполнения процедуры аж три раза, я буду знать куда обратиться. Приходишь на форум и все здесь. Послушать вас, так несколько миллионов записей с 3 х гетдатом в одной таблице имеют очень большой смысл. Особенно когда надо (сгруппироровать/выбрать/вернуть в аппликацию) данные по дням, месяцам, неделям, кварталам, годам. Особенно замечательно будет выглядеть партитион вьюшка для репортинга на базе такой таблички. Я уже не говорю о том, что в селекте юзать функцию для преобразования датового типа - не есть гуд. Даже НЕэксперт по базам напишет cast( convert( char(8), data, 112) as int) могут существовать задачи, для которых именно такой вариант есть логичный и правильный Арчер, приведи пример.Ты меня так заинтриговал, что я весь в интересе. За каким нужно в одной таблице 3 поля с абсолютно одинннаковым значением меняющемся после каждого выполнения процедуры, даже если абстрагироваться от написанного выше. Quote Sdílet tento příspěvek Odkaz na příspěvek Sdílet na ostatní stránky