Докатился. Пришлось всю неделю преподавать курс по администрированию 2008 сиквела. А что поделать, некому было.

Обнаружил полную бесполезность этого поля и типа данных при работе с репликацией и копированием. Оно не решает задачи определения какое изменение произошло последним. Кроме этого имеет глупое ограничениеЖ нельзя использовать к этому полю default, которое смогло бы решить вышепоставленную задачу.

Чудны дела микрософта. Подгоняя всех к переходу на 64-разрядные системы, забывают про обратную совместимость. На сей раз речь идет о весьма важной составляющей - OLEDB и ODBC.

В отношении 64-разрядного MS SQL Server проблема проявится при использовании linked servers/openrowset/openquery. Несмотря на наличие 64-разрядного OLEDB в составе Vista SP1 и Windows Server 2008, а также недавно выпущенного обновления для Windows Server 2003, устанавливающего OLEDB64, сделана только половина дела.

Провайдер OLEDB для Jet равно как и 64-разрядные ODBC-драйверы для доступа к Excel, Access и текстовым файлам отсутствуют. Планов по переносу Jet на 64 разряда у Microsoft нет, так как он вытесняется версиями SQL Server Personal/Compact. Драйверы ODBC пока даже не аннонсированы.

В качестве "обхода" проблемы консультанты MS на форумах предлагают создать приложение под SSIS, но скомпилировать его в 32-разрядном (!) варианте. В ответ слышится прикрытый вежливыми оборотами мат. В самом деле, можно понять разработчиков, которым теперь потребуется переделывать подсистемы импорта/экспорта.

В итоге имеем очередные достаточно серьёзные грабли, вызванные плохим обеспечением обратной совместимости. При переходе на 64-разрядные версии продуктов MS будьте готовы к проблемам на уровне интеграции данных.

Информация о дисковом пространстве, используемом таблицами текущей базы данных.

DECLARE @TableInfo TABLE (
  table_name sysname ,
  row_count int,
  reserved_size nvarchar(50),
  data_size nvarchar(50),
  index_size nvarchar(50),
  unused_size nvarchar(50))

INSERT INTO @TableInfo 
EXEC sp_MSforeachtable 'sp_spaceused ''?'''

SELECT * FROM @TableInfo ORDER BY table_name

К заметке о том, как можно организовать последовательность (счетчик) уникальных целочисленных значений на MS SQL Server впору добавлять конкурс на самую шедевральную реализацию. Так сказать, "шедевры" мировой софтостроительной архитектуры.

Начну с такого примера.

Немного теории

Если кто-то забыл, что такое транзакция, то напомню: упорядоченное множество действий, которые выполняются или все вместе или не выполняются вовсе. В применении к SQL транзакция включает в себя один и более операторов языка. Уровни изоляций транзакций с разной степенью обеспечивают целостность данных при их одновременной обработке множеством процессов (пользователей). Наиболее простой вариант известен всем: один пользователь записывает информацию на уровне записи таблицы, другой пытается ее прочитать. При отсутствии изоляции второй пользователь может прочитать данные незавершенной транзакции. Ситуация качественно усложняется, если изменениям (модификации, вставке, удалению) подвержена не одна запись, а несколько, возможно даже в разных таблицах.

Назначение

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

Обе проблемы могут быть решены введением над SQL макроязыка. А поможет нам в этом достаточно простая утилита SPM (SQL Programming Macroprocessor), основанная на фактически стандартном для UNIX-среды макропроцессоре GNU m4.

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

Как-то незаметно в блоге возникла целая коллекция заметок на тему неотвратимого "прогресса" от Microsoft (см. Когда вредные советы полезны, Браузеры, Интерфейс в новом Office 2007, Windows Vista: добровольно и с песнями, Разработчики объясняют, почему они избегают Vista).

Пришла пора сказать пару слов за SQL Server...

Подниму старую тему, так как появились дополнения.

Предыстория вопроса. В 2005 году я разрабатывал OLEDB-провайдер для самописной СУБД. Ранее без особых проблем примерно за неделю был написан .NET Data Provider, но он, к сожалению, работал только в .NET-среде. А тут встала потенциальная задача синхронизации баз данных с MS SQL 2000. Одна из эффективных ее реализаций - репликация на гетерогенного подписчика: MS SQL сам передает все изменения другой СУБД через OLEDB или ODBC-интерфейсы.