Foreign Key на ComputedColumn

Попал в засаду при обратном переносе проги, отлаженной под SQL2005 на SQL2000.

Разве в SQL2000 нельзя сделать Subj?

Cannot create the foreign key 'FK_PR_Groups_SY_Image' because the referenced column 'SY_Image.Key' is a computed column.

Значит, нельзя. Так backward-compatibility никто и не обещал.

А не пробовали создать уникальный индекс на вычисляемое поля? Может быть получится.

ОФФ.
Не могу представить себе задачу, в которой нужна такая штука. Вообще ни одной идеи.

Уникальный создает, но этого мало нужен именно PRIMARy

To GreenSunrise.

Странно, что вы этого себе не представляете. Ведь вы же умнейший человек (хоть и скриншофоб). Я вам положил во вложении один маленький фрагмент своей системы, которую я как раз пытался выставить сегодня на боевом сервере (который оказался 2000-м) - ну а мой девелоперский - 2005-й.
Вот посмотрите там сверху есть табла SY_IMAGE. Это табла графического ядра системы (отчего у нее префикс SY, а не прификс прикладной подсистемы) - а вообще во всем этой моей проделке таблиц -сотни.
Так вот вернемся к SY_IMAGE - это централлизованное хранилище всех чертежей и рисунков.Соответственно у нее есть первичный ключ - на который завязаны таблы и отдельными комплектами рисунков - ну скажем PR_GROUP, PR_ClassifierList, PR_ClassTypeList, ну и множество других.
Сама табла организована так:

CREATE TABLE [dbo].[SY_Image](
	[i] [int] IDENTITY(1,1) NOT NULL,
	[Key]  AS (N'i'+CONVERT([nvarchar](5),[i],0)) PERSISTED NOT NULL,
	[Image] [image] NULL,
	[Alias] [nvarchar](50) COLLATE Cyrillic_General_CI_AS NULL,
 CONSTRAINT [pkPR_Image] PRIMARY KEY CLUSTERED 
(
	[Key] ASC
)WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

Так вот фишка в том, что графическое ядро (которое тоже писал я) работает с неуправляемым кодом, проще говоря с элементами ImageList. А этот самый гребаный ImageList принимает в качестве ключа ТОЛЬКО нечисловое поле. А поскольку все отображаемые столбцы ТИПИЗИРОВАНЫ, те в столбце типа PR_GROUP не может быть того же рисунка, что и в столбце типа PR_ClassifierList, НО само хранилище рисунков SY_IMAGE - едино - то уникальный ключ рисунка так и идет по все системе, как определен в SY_IMAGE -

[Key]  AS (N'i'+CONVERT([nvarchar](5),[i],0)) PERSISTED NOT NULL

В общем, всю эту пирамиду я сегодня все равно так и не выставил до конца. Уровень SQL - выставил - правда без этого важнейшего ограничения целостности... Пока все выставлял - накатила ночь. Не успел выставить самое главное - множество прог. Фишка оказалась в чем. Там часть прог на .NET2, которой, блин, невозможно поставить без INSTALLER 3.0

А там на месте я его так и не смог скачать с MS-сайта без проверки Win на подлинность. Пока остановился на этом. Буду пока переделывать все равно кое-что.

Еще... кто-нибудь даст ссылку на Installer 3.0 (ну или 3.1) без гиморроя с Geniune Windows?

А в каком именно неуправляемом коде находится imagelist, и почему нельзя делать строку из числа для целей его ключа прямо при сохранении ключа в imagelist? И зачем добавление 'i'? Вот, к примеру, VB, если его заставить сделать "5"+5 (да простят мне сей ужас), выдаст 10, но если Collection.Add "5", то ключ останется строкой "5" и не будет переведён в число...

Сделать можно все на свете. И как угодно. Но, я уже сделал примерно так, как на рисунке - те с уровня данных рисунки поднимаются УЖЕ с нормально сформированным ключом.
И переписывать, начиная с самого ядра системы - у меня нет ни малейшего желания, ибо это 10,4 тыс строк кода только в SQL+VB6. Плюс огромная часть код на NET2 (который из-за гребаного инсталлера не удалось вчера даже установить).

Вот прикол. Инсталлер 3.0 нашел на дистрибутиве SQL2005

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

Может, я до конца не понимаю вашу ситуацию, но имхо самым нормальным способом было бы ключи (PK, FK) иметь числовые, а для клиентских выборок, если уж так загадочно (вами же) написан графический интерфейс, иметь вычисляемое поле. Ну и были бы ключи по int, а выборка по varchar.

Кстати, временами переписывание клиентского кода, когда выясняется его несостоятельность, обходится дешевле, чем извращения на стороне сервера.