авторВ Юконе как раз можно будет так писать, как в конце той страницы. Получается, что уже можно сравнивать - бета есть :)
Сам Юкон не видел, но на вскидку там будут:
CTE, Recursive, Date, Time, C# ... есть ли что еще из списка фич других СУБД ?

Насколько помню:
не будет триггеров BEFORE и EACH ROW, если что поправьте.

Возникает еще вопрос многостродальной теме C# в MSSQL - он там будет только как язык ХП использоваться или же на C# можно делать классы, которые обьявлять как домены и хранить их экземпляры в таблицах ? Типа как в ASA (берем кусок BOL):
здесь хотя бы видна польза Java - можно хранить в таблицах обьекты и работать с ними напрямую с запросов. Несмотря на это, постоянное развитие WatcomSQL вытеснило Java и она обьявлена в ASA как "не рекомендуемая опция", т.е. не факт что в следующей верстии поддержку работы с Java из WatcomSQL не снесут, оставив только внешние ХП на Java.

tygra авторХм. Sequence отличается от Identity очень простым образом - уж простите, не понял, что есть "выше". Sequence - это объект, с которым как хочешь, так и работаешь. А identity - это нечто вроде атрибута поля и "ни шага влево, ни шага вправо". По крайней мере, если опять же ничего не изменилось по сравнению с версиями, о которых мне рассказывали.

Guid же, насколько я понимаю, является "ответом на sequence" потому что позволяет MSSQL нормально реплицироваться - чего (насколько я в курсе) не умеет identity.
Ну секвенс то аналог identity вообще-то. А гуид - это просто другой тип данных. Какая связь?
Ну а репликация - а как тут секвенс связан с ней?

-- Tygra's --
Гм, возможно аналогу секвенса в ASA служит Global Autoincrement - который ведется непрерывно для всей БД, но в пределах, заданных в опции "Database ID". В итоге все работают каждый в пределах своего промежутка значений, в консолидированной БД не возникает конфликтов PK, однако в самой консолидированной БД счетчик под ее DataBase id не сбивается при подливе данных с других СУБД и все вставляемые записи опять же работают в собственном промежутке, таким образом избегая обратных конфликтов. Все это работает автоматом, единственное где могут быть траблы при репликации - это при сбивании кода БД или же ввода одинаковых, однако это уже на совести проектировщика. Конечно самое надежное конечно это GUID - тут вообще никаких конфликтов быть просто не может, хотя если сравнивать bigint и GUID - немного разные размеры типов данных получаются.

Alex.CzechStart value и seed value у IDENTITY безусловно настраиваются... так что имхо для репликации никаких проблем я не вижу. Вот когда нужно одно ID на несколько таблиц сразу автоинкрементить - это и есть те самые 5% (о которых я говорил в другом топике), где identity проигрывает
Ради интереса - настраиваться то понятно настраивается. А вот не сбивается ли, если с других БД приходят записи с заведомо более высоким диапазоном номеров ? То есть работает у нас Identity в пределах 1-100 и равен 2, приходит с другой БД запись 101. Какой следующий номер будет присвоен при вставке новой записи в этой таблице ? По идее он должен равняться 3-ем.

авторА вообще прискорбно, что все это вылилось в очередную религиозную войну. "Нет, не об этом он мечтал всю свою сознательную жизнь"
Да нет - даже ссылочки интересные по Юкону привели, с удовольствием почитал, как там и чего будет выглядеть в целях самообразования. Есть правда один неутешительный вывод - формула "ПО от MS = Геммор" к сожалению продолжает успешно работать и они где нибудь, да обязательно сделают пару недоработок/ошибок, которые потом придется дружно обходить.

авторБлин... чтобы узнать Identity-значение нужно обядательно вставить строку в таблицу. (сделать транзакцию) Последнее значение возвратится в @@identity. Чтобы получить значение из последовательности - нужно сделать запрос, который находится все транзакции. Разница - ОГРОМНА!
Давненько Вы с MSSQL не работали :) Уже давно есть куча функций, которая позволяет вне транзакции без вставки записи узнавать для указанных таблиц текущий и следующий Increment.