Здравствуйте, 4erniyPlasch, Вы писали:
P>Дык, чтобы сравнить. Мне его надо куда-то считать, потом считанное уже сравнивать. Считывать мне удобнее в int, чтобы проблем с форматом даты не иметь...
Ну так и сравнивай 8 байт. Честно говоря я даже не представляю как ты собираешься 8 байт в int запихнуть. А о том, что timestamp имеет отношение к дате лучше вообще забыть.
Здравствуйте, Lloyd, Вы писали:
L>Не знаю как у тебя, а у меня int имеет вполне конкретный размер (4 байта).
А это смотря какая версия сервака стоит на машине (64bit или 32bit)
Здравствуйте, 4erniyPlasch, Вы писали:
P>СУБД MSSQL.
P>Считал значение timstamp — получил массив из 8 байт. Что мне с ним делать? Будет нормально если я его к int или строке приведу приведу или нет?
На стороне сервера я делаю одно из преобразований: cast(TS as datetime),cast(TS as int)
Здравствуйте, 4erniyPlasch, Вы писали:
P>СУБД MSSQL.
P>Считал значение timstamp — получил массив из 8 байт. Что мне с ним делать? Будет нормально если я его к int или строке приведу приведу или нет?
Для timestamp-а никаких операций кроме сравнения с другим timestamp-ом делть не надо, так что не совсем понятно зачем тебе приводить его к чему-то?
Здравствуйте, Lloyd, Вы писали: L>Для timestamp-а никаких операций кроме сравнения с другим timestamp-ом делть не надо, так что не совсем понятно зачем тебе приводить его к чему-то?
Дык, чтобы сравнить. Мне его надо куда-то считать, потом считанное уже сравнивать. Считывать мне удобнее в int, чтобы проблем с форматом даты не иметь...
Здравствуйте, Lloyd, Вы писали: L>Ну так и сравнивай 8 байт. Честно говоря я даже не представляю как ты собираешься 8 байт в int запихнуть. А о том, что timestamp имеет отношение к дате лучше вообще забыть.
В int запихивается моментально — на стороне сервера convert(int,myfield). В datetime тоже самое.
Вас смущает, что там 8 байт, а не 4? Так int тоже разный бывает...
Здравствуйте, 4erniyPlasch, Вы писали:
P>СУБД MSSQL.
P>Считал значение timstamp — получил массив из 8 байт. Что мне с ним делать? Будет нормально если я его к int или строке приведу приведу или нет?
timestamp — binary(8) никакого отношения к дате и времени не имеет. Правильнее будет использовать синоним rowversion. Его вообще не надо преобразовывать, т.к. есть смысл сравнивать его только с binary(8), т.е. с другим сохраненным значением timestamp или результатом ф-ции @@dbts
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Аноним, Вы писали:
А>>А это смотря какая версия сервака стоит на машине (64bit или 32bit) L>идите в BOL.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, 4erniyPlasch, Вы писали:
___>timestamp — binary(8) никакого отношения к дате и времени не имеет. Правильнее будет использовать синоним rowversion. Его вообще не надо преобразовывать, т.к. есть смысл сравнивать его только с binary(8), т.е. с другим сохраненным значением timestamp или результатом ф-ции @@dbts
Это не совсем правда, timespam это безнаковое 64 битное целое, чем больше это число тем позже был получин timespam. Из операций часто полезно использовать min, max, >, <, =.
Здравствуйте, Lloyd, Вы писали: L>Ну так и сравнивай 8 байт. Честно говоря я даже не представляю как ты собираешься 8 байт в int запихнуть. А о том, что timestamp имеет отношение к дате лучше вообще забыть.
Приведу цитату одного мудреца из др. форума:
"Это своего рода DB-wide identity — последовательно увеличивающиеся значения в диапазоне bigint. К дате/времени отношения никакого не имеет, если конечно речь идет о типе timestamp в понимании MSSQL 2000, а не SQL-92. Вообще же, более корректно было бы называть его rowversion, дабы избежать путаницы."
Здравствуйте, 4erniyPlasch, Вы писали:
L>>Не знаю как у тебя, а у меня int имеет вполне конкретный размер (4 байта).
P>Да у меня тоже — просто 2^4 это гораздо больше чем мне надо, так что до 2^8 дело не дойдет...
Что такое 2^4? 8 байт — это 2^(8*8).
Здравствуйте, kon_v_palto, Вы писали:
__>Здравствуйте, _d_m_, Вы писали:
___>>Здравствуйте, 4erniyPlasch, Вы писали:
___>>timestamp — binary(8) никакого отношения к дате и времени не имеет. Правильнее будет использовать синоним rowversion. Его вообще не надо преобразовывать, т.к. есть смысл сравнивать его только с binary(8), т.е. с другим сохраненным значением timestamp или результатом ф-ции @@dbts
__>Это не совсем правда, timespam это безнаковое 64 битное целое, чем больше это число тем позже был получин timespam. Из операций часто полезно использовать min, max, >, <, =.
Эээ... Так где я сказал "не совсем правду"? rowversion представлен типом binary(8) (ссылкой тыкать?), что в принципе и представляет из себя 64 битное беззнаковое целое.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, kon_v_palto, Вы писали:
___>Эээ... Так где я сказал "не совсем правду"? rowversion представлен типом binary(8) (ссылкой тыкать?), что в принципе и представляет из себя 64 битное беззнаковое целое.
___>"timestamp — binary(8) никакого отношения к дате и времени не имеет."
чем больше это число тем позже был получин timespam ___>"Его вообще не надо преобразовывать, т.к. есть смысл сравнивать его только с binary(8)"
А операции больше меньше для binary есть, и в клиенте с Byte[] работать очень удобно.
___>Кстати, полезно для чего? Для здоровья?
Ну например для выборки обновлений из базы вроде
SELECT * FROM "Table" WHERE "ts" > @max_ts
где "ts" столбец timestamp, @max_ts максимальное значение "ts" данных сохраненных на клиенте. Конечно проблема с удаленными строками, ну думаю сам догадаешся как ее разрешить.
Здравствуйте, 4erniyPlasch, Вы писали:
L>>Ну так и сравнивай 8 байт. Честно говоря я даже не представляю как ты собираешься 8 байт в int запихнуть. А о том, что timestamp имеет отношение к дате лучше вообще забыть.
P>Приведу цитату одного мудреца из др. форума:
P>
P>"Это своего рода DB-wide identity — последовательно увеличивающиеся значения в диапазоне bigint. К дате/времени отношения никакого не имеет, если конечно речь идет о типе timestamp в понимании MSSQL 2000, а не SQL-92. Вообще же, более корректно было бы называть его rowversion, дабы избежать путаницы." P>
Ты к чему это привел?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, 4erniyPlasch, Вы писали:
L>>>Не знаю как у тебя, а у меня int имеет вполне конкретный размер (4 байта).
P>>Да у меня тоже — просто 2^4 это гораздо больше чем мне надо, так что до 2^8 дело не дойдет... L>Что такое 2^4? 8 байт — это 2^(8*8).
Здравствуйте, 4erniyPlasch, Вы писали:
P>Считал значение timstamp — получил массив из 8 байт. Что мне с ним делать? Будет нормально если я его к int или строке приведу приведу или нет?
Если очень надо получить timestamp (rowversion) на клиенте, то byte[8] будет в самый раз.
Здравствуйте, kon_v_palto, Вы писали:
__>Здравствуйте, _d_m_, Вы писали:
___>>Здравствуйте, kon_v_palto, Вы писали:
___>>Эээ... Так где я сказал "не совсем правду"? rowversion представлен типом binary(8) (ссылкой тыкать?), что в принципе и представляет из себя 64 битное беззнаковое целое.
___>>"timestamp — binary(8) никакого отношения к дате и времени не имеет." __>чем больше это число тем позже был получин timespam
И что? По твоему это значит, что "имеет отношение к дате-времени"?
Или я где-то оспорил, что: "чем больше это число тем позже был получин timestamp"
___>>"Его вообще не надо преобразовывать, т.к. есть смысл сравнивать его только с binary(8)" __>А операции больше меньше для binary есть, и в клиенте с Byte[] работать очень удобно.
А я говорил, что нет операций сравнения? Читай внимательно, думай, затем пиши.
___>>Кстати, полезно для чего? Для здоровья?
__>Ну например для выборки обновлений из базы вроде __>
__>SELECT * FROM "Table" WHERE "ts" > @max_ts
__>
__>где "ts" столбец timestamp, @max_ts максимальное значение "ts" данных сохраненных на клиенте. Конечно проблема с удаленными строками, ну думаю сам догадаешся как ее разрешить.
Ну спасибо, не отказал мне в малой толике интеллекта.
Теперь для тех кто в танке, еще раз: речь шла о преобразовании timestamp <-> datetime или timestamp <-> int. На что я ответил, "что нет необходимости в никакаких преобразованиях". А ты мне приплел непонятно что, или это способ таким образом показать свое знание вопроса?. Вот в приведенном тобой запросе какого типа @max_ts? Позволь мне догадаться: binary(8), а столбец "ts", соответсвенно типа rowversion (timestamp). И нет никаких преобразований в datetime или int, bigint. Яволь?
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, kon_v_palto, Вы писали:
__>>Здравствуйте, _d_m_, Вы писали:
___>>>Здравствуйте, kon_v_palto, Вы писали:
___>>>Эээ... Так где я сказал "не совсем правду"? rowversion представлен типом binary(8) (ссылкой тыкать?), что в принципе и представляет из себя 64 битное беззнаковое целое.
___>>>"timestamp — binary(8) никакого отношения к дате и времени не имеет." __>>чем больше это число тем позже был получин timespam
___>И что? По твоему это значит, что "имеет отношение к дате-времени"? ___>Или я где-то оспорил, что: "чем больше это число тем позже был получин timestamp"
___>>>"Его вообще не надо преобразовывать, т.к. есть смысл сравнивать его только с binary(8)" __>>А операции больше меньше для binary есть, и в клиенте с Byte[] работать очень удобно.
___>А я говорил, что нет операций сравнения? Читай внимательно, думай, затем пиши.
Я горорю что их нет для byte[] ни в одном языке.
___>>>Кстати, полезно для чего? Для здоровья?
__>>Ну например для выборки обновлений из базы вроде __>>
__>>SELECT * FROM "Table" WHERE "ts" > @max_ts
__>>
__>>где "ts" столбец timestamp, @max_ts максимальное значение "ts" данных сохраненных на клиенте. Конечно проблема с удаленными строками, ну думаю сам догадаешся как ее разрешить.
___>Ну спасибо, не отказал мне в малой толике интеллекта. ___>Теперь для тех кто в танке, еще раз: речь шла о преобразовании timestamp <-> datetime или timestamp <-> int. На что я ответил, "что нет необходимости в никакаких преобразованиях". А ты мне приплел непонятно что, или это способ таким образом показать свое знание вопроса?. Вот в приведенном тобой запросе какого типа @max_ts? Позволь мне догадаться: binary(8), а столбец "ts", соответсвенно типа rowversion (timestamp). И нет никаких преобразований в datetime или int, bigint. Яволь?
Каким хреном ты собераешся искать @max_ts ?
Полный код:
CREATE PROCEDURE SelectNew(@max_ts bigint) AS
SELECT ... , CAST("ts" AS bigint) AS "ts"
FROM "Table_" WHERE (@max_ts is null)or("ts" > @max_ts)
go
Ich habe kein Lust mit dir weitert zu diskutieren.
Tshcuss.
___>>А я говорил, что нет операций сравнения? Читай внимательно, думай, затем пиши.
__>Я горорю что их нет для byte[] ни в одном языке.
Вобще-то речь идет о T-SQL. За каким хреном мне надо сравнивать что-то на клиенте? Это даже элементарно не эффективно. В твоем примере, кстати, тоже T-SQL.
__>Каким хреном ты собераешся искать @max_ts ?
__>Полный код: __>
__>CREATE PROCEDURE SelectNew(@max_ts bigint) AS
__>SELECT ... , CAST("ts" AS bigint) AS "ts"
__>FROM "Table_" WHERE (@max_ts is null)or("ts" > @max_ts)
__>go
__>
Ага. И получаем полный скан таблицы. Для чего?
У меня "макс тэ эсы" в БД храняться. И тягать их на клиента есть смысл только для временного хранения во время сессии репликации. Для чего успешно используется тип SqlBinary. А код твоей процедуры должен выглядеть так:
CREATE PROCEDURE SelectNew(@max_ts binary(8)) AS
SELECT ... , "ts" FROM "Table_" WHERE (@max_ts is null)or("ts" > @max_ts)
__>Ich habe kein Lust mit dir weitert zu diskutieren. __>Tshcuss.
Это типа ты меня на немецком на х... послал? Ну-ну...
Здравствуйте, _d_m_, Вы писали:
__>>Ich habe kein Lust mit dir weitert zu diskutieren. __>>Tshcuss.
"Мене не интересно с тобой далее дискутировать.
Пока." ___>Это типа ты меня на немецком на х... послал? Ну-ну...
P.S. Если не знаеш языка не начинай на нем разговаривать(писать).
Здравствуйте, kon_v_palto, Вы писали:
__>>>Ich habe kein Lust mit dir weitert zu diskutieren. __>>>Tshcuss. __>"Мене не интересно с тобой далее дискутировать. __>Пока."
Ну и тебе не скучать.
___>>Это типа ты меня на немецком на х... послал? Ну-ну...
__>P.S. Если не знаеш языка не начинай на нем разговаривать(писать).
Мы уже победили, просто это еще не так заметно...
