MS SQL синхронизация / Timestamp

← →
TohaNik © (2014-11-13 19:31) [40]

> После выполнения запроса:select @newTimeStamp=max(timestamp)
> from MyTableМожет ли в MyTable появиться запись, у которой
> timestamp будет меньше или равен @newTimeStamp?

Может, он не для этого.
Блокировки нужны... ИМХО

← →
Inovet © (2014-11-13 19:38) [41]

> [27] Труп Васи Доброго © (13.11.14 13:53)
> Где грибочки брал и сколько стоят?

Может быть, имелась ввиду предварительная проверка до проверки средствами сервера...

← →
Кщд © (2014-11-14 10:42) [42]

>TohaNik © (13.11.14 19:31) [40]
http://msdn.microsoft.com/ru-ru/library/ms152531.aspx
чем не устраивает?

← →
TohaNik © (2014-11-14 11:11) [43]

Да нормально, в 99, 99, а больше и не надо... Просто как по мне, пусть лучше приложение вылетит, чем разбирать: а откуда эта запись взялась. Это о ключах, суррогатных... и разных

← →
Ega23 © (2014-11-14 11:44) [44]

> Может ли в MyTable появиться запись, у которой timestamp
> будет меньше или равен @newTimeStamp?

может.

← →
Кщд © (2014-11-14 11:49) [45]

>Ellisium © (13.11.14 19:09) [38]
вы за два дня не способны прочитать документацию?
срываю покровы: http://msdn.microsoft.com/en-us/library/ms182776.aspx
но ключевое слово для вас: репликация
а не велосипед

← →
Ega23 © (2014-11-14 12:50) [46]

> срываю покровы

Да тоже непонятно. Вдруг у него данные в приёмнике тоже меняются как-то?

← →
junglecat © (2014-11-14 12:55) [47]

репликация слиянием?
http://technet.microsoft.com/en-us/library/ms151329(v=sql.105).aspx

← →
Кщд © (2014-11-14 13:07) [48]

>TohaNik © (14.11.14 11:11) [43]
вы пьяны?

← →
TohaNik © (2014-11-14 13:24) [49]

Угу, ищу старых знакомых...Ну сделайте номер,ФИО, или код там какой. еще чего то добавьте- ответит любовью

← →
Ellisium © (2014-11-15 20:05) [50]

> Может

> может.

можно пример алгоритма действий, когда после выполнения запроса:

select @newTimeStamp=max(timestamp) from MyTable

в таблице MyTable появится запись c timestamp равным или меньше @newTimeStamp?

← →
Кщд © (2014-11-15 22:18) [51]

>Ellisium © (15.11.14 20:05) [50]
нужно прочитать документацию
приведенных ссылок достаточно для ответа на ваш вопрос

← →
Ellisium © (2014-11-16 13:26) [52]

Ссылки я читал, ситуацию для меня они не прояснили - потому и спрашиваю

← →
Кщд © (2014-11-16 21:03) [53]

http://msdn.microsoft.com/en-us/library/ms182776.aspx
"Each database has a counter that is incremented for each insert or update operation that is performed on a table that contains a rowversion column within the database. This counter is the database rowversion. "

вы ТОЧНО читали документацию?

← →
Ellisium © (2014-11-17 09:26) [54]

>вы ТОЧНО читали документацию?

Да. Из цитаты я делаю вывод что ответ на мой вопрос - нет, не может. Но тут кругом люди пишут что может появится запись с timestamp меньше. Я не понимаю как такое может получиться

← →
Юрий Зотов © (2014-11-17 14:26) [55]

> Ellisium © (17.11.14 09:26) [54]
> Я не понимаю как такое может получиться

Навскидку, возможен такой сценарий.
1. Юзер1 делает select и получает new_Ts = max(поле)+добавка. 2. Юзер1 делает insert (или update) с new_Ts, но еще не коммитит. 3. Юзер2 делает тот же самый select и получает то же самое new_Ts. 4. Юзер1 коммитит. Появляется запись с new_Ts. 5. Юзер2 делает insert (или update) с new_Ts. 6. Юзер2 коммитит. Появляется вторая запись с new_Ts.
Но могу и ошибаться, БД - не моя стихия.

← →
Юрий Зотов © (2014-11-17 14:40) [56]

Вообще, полагаться на уникальное значение Timestamp вряд ли стоит - могут быть совпадения из-за слишком большой дискретности. Например, в документации по DB2 для IBM AS/400 прямо сказано, что так делать нельзя, а надо использовать функцию Create_Unique(Timestamp).

← →
Ellisium © (2014-11-17 17:33) [57]

Дядь Юр, спасибо за попытку помочь , но вы не читали что такое timestamp. Почитайте хотя бы что написано в [53]

← →
Юрий Зотов © (2014-11-17 18:45) [58]

> Ellisium © (17.11.14 17:33) [57]

До сих пор я полагал что timestamp - это тип данных.

← →
Ellisium © (2014-11-17 19:33) [59]

> До сих пор я полагал что timestamp - это тип данных.

это и есть тип данных. Но он не имеет отношения к времени (datetime) в MS SQL и трансляция его во время невозможна. Это скорее уникальный счетчик, уникальный в пределах инстанса БД за мелкими исключениями.

← →
Ellisium © (2014-11-17 19:39) [60]

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

Критика только в том, что поскольку timestamp глобальный идентификатор по сути, то max(timestamp) from MyTable - это может занять много ресурсов, а лучше использовать MIN_ACTIVE_ROWVERSION

← →
Ellisium © (2014-11-17 19:40) [61]

Заодно привет знатокам в виде TohaNik и Ega23

← →
Ellisium © (2014-11-17 19:44) [62]

В особенности, конечно, Ega23, который сначала дает ссылку на: http://technet.microsoft.com/ru-ru/library/bb726005%28v=sql.110%29.aspx

а потом говорит что-то про timestamp и часовые пояса UTC. Мог бы хоть минуту почитать собственную ссылку. Вот как так можно помогать :))

Всем спасибо.

← →
картман © (2014-11-17 19:49) [63]

> Ellisium © (17.11.14 19:44) [62]

> В особенности, конечно, Ega23, который сначала дает ссылку
> на: http://technet.microsoft.com/ru-ru/library/bb726005%28v=sql.
> 110%29.aspx
>
> а потом говорит что-то про timestamp и часовые пояса UTC.
> Мог бы хоть минуту почитать собственную ссылку.

ну да, а тебе, как автору, прочесть по той же ссылке не судьба была:
Тип данных rowversion является увеличивающимся числом и не основан на дате или времени.
пришлось
> поговорил я с шарящими людьми

← →
Кщд © (2014-11-17 20:24) [64]

>Ellisium © (17.11.14 19:44) [62]
вам шашечки или ехать?
если ехать, то в доке всё написано

← →
Ega23 © (2014-11-18 03:29) [65]

> В особенности, конечно, Ega23

Ega23 уже 300 лет с MSSQL дела не имел.

Но если судить по доке, то timestamp - суть deprecated type, должен использоваться rowversion. Судя по описанию rowvwrsion, он инкрементируется на каждый чих по изменению данных (и я там ещё не сильно вникал в транзакционность, типа, значение не откатывается).
Таким образом, ежели в таблице-приёмнике данные меняются, то rowversion однозначно расползётся с таблицей-источником. А значит, что надо на больше-равно сравнивать. А это, в свою очередь означает, что в некоторой перспективе все данные в таблице будут попадать под это условие, и что проще таблицу целиком скопипастить.
О чём кое-кому уже говорилось.

← →
Ega23 © (2014-11-18 08:49) [66]

Ух-ты. Прикольный у меня в полчетвёртого полёт фантазии.

← →
Ellisium © (2014-11-18 18:48) [67]

> Ega23 уже 300 лет с MSSQL дела не имел.

ну а зачем тогда так категорично в [44] утверждать:

> может.

← →
Кщд © (2014-11-18 18:51) [68]

>Ellisium © (18.11.14 18:48) [67]
пожалуйста, используйте штатные средства для репликации
пока-что вы даже доку не в силах осмыслить

> Судя по описанию rowvwrsion, он инкрементируется на каждый
> чих по изменению данных (и я там ещё не сильно вникал в
> транзакционность, типа, значение не откатывается).

Это просто другое имя, для соместимости со стандартами, можешь использовать и старое имя, ничего в данный момент не изменится.
Вот выписка из справки http://msdn.microsoft.com/ru-ru/library/ms182776.aspx

> Тип данных timestamp является синонимом типа данных rowversion
> и подчиняется правилам поведения синонимов типа данных.

И откатываться он не должен, для обеспечения целостности, как и первичный ключ

Остается маленький вопрос как с ним работать из Delphi.

Студия его представляет в виде: 0x000000000014B46F

Но как из дельфи составить запрос с этим timestamp...

> Но как из дельфи составить запрос с этим timestamp...

Тип binary(8) или varbinary(8)

> Тип binary(8) или varbinary(8)

и?

SomeQuery.ParamByName("TS").Value := $000000000014B46F;

> SomeQuery.ParamByName("TS").Value := $000000000014B46F;

Delphi вроде это представляет тогда как LongWord...

А если большое число - то как UInt64...

Наверное, тогда с ним так и надо работать, как с UInt64...

кстати, как с UInt64 - не получилось почему-то (((

Работаю как с Variant... Читаю в Variant, а потом в параметр пишу, как Variant - работает. Не разбирался.

Может немного не в тему, но есть заковырка с timestamp в mssql - он может округляться (или терять точность, не знаю).
Была значит колонка типа timestamp, в которой хранились только даты (тип date в mssql, по-моему, только в 2008 версии запилили), а время всегда в 0 было. Нужно было пофильтровать записи по какой-то дате. Был запрос типа

select * from table_t where date_p>=10.10.2012 00:00:00.000 and date_p<=10.10.2012 23:59:59.999

Так в выборку попадали записи за 11.10.2012, т.к. mssql представил 10.10.2012 23:59:59.999 как 11.10.2012 00:00:00.000. В чем он там у себя внутри даты хранит - может в double, не знаю, но факт остается фактом.
Пришлось переписать запрос на строго меньше начала следующего дня.

select * from table_t where date_p>=10.10.2012 00:00:00.000 and date_p<11.10.2012 00:00:00.000

> Пришлось переписать запрос на строго меньше начала следующего
> дня

и это правильный вариант.

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

MS SQL синхронизация / Timestamp Найти похожие ветки