Я новичок в SQL Azure и на ранних этапах разработки приложения, поэтому моя схема часто меняется. Я начал с создания корневой базы данных и выполнения запросов к ним, как этиSQL Azure. Определите, какие таблицы объединены.
CREATE TABLE [dbo].[Clients] (
[ClientId] UNIQUEIDENTIFIER NOT NULL primary key clustered default newid(),
[ClientName] NVARCHAR (MAX) NULL
);
go
create federation ClientFederation(cid uniqueidentifier range)
go
use federation ClientFederation(cid='00000000-0000-0000-0000-000000000000') WITH RESET, FILTERING=OFF
go
CREATE TABLE [dbo].[Stuff] (
[StuffId] uniqueidentifier not null default newid(),
[ClientId] UNIQUEIDENTIFIER NOT NULL default federation_filtering_value('cid'),
[StuffName] NVARCHAR (50) NOT NULL,
-- bunch (20+) of other fields
primary key clustered (StuffId, ClientId ASC)
) FEDERATED ON (cid=ClientId);
И это работало довольно хорошо по большей части. Stuff - всего одна таблица среди многих подобных таблиц в федерации (а не настоящее имя)
Ну, как я уже сказал, моя схема меняется довольно часто, поэтому, чтобы изменить схему, я подключаюсь к член федерации в VS2012 и правой кнопкой мыши на таблице и выбрав «View Code», который делает что-то вроде этого:
CREATE TABLE [dbo].[Stuff] (
[StuffId] uniqueidentifier not null default newid(),
[ClientId] UNIQUEIDENTIFIER NOT NULL default federation_filtering_value('cid'),
[StuffName] NVARCHAR (50) NOT NULL,
-- bunch (20+) of other fields
primary key clustered (StuffId, ClientId ASC)
)
Обратите внимание, единственное, что отличается не в том, что после закрытия скобок, он больше не говорит FEDERATED ON (cid=ClientId);. Я предполагал, что это связано с тем, что я уже подключен к определенному члену федерации, поэтому он уже знал эту информацию. Странная часть - это когда я пытался запустить какой-то код .net. Я бы выполнить следующий код из моего приложения:
cn.Execute(string.Format("USE FEDERATION {0}({1}='{2}') WITH RESET, FILTERING={3}", federationName, distributionName, key, filtered ? "ON" : "OFF"));
, а затем с помощью щеголеватый:
cn.Query("INSERT Stuff(StuffId, StuffName) VALUES (@StuffId, @stuffName); SELECT * FROM Stuff WHERE [email protected]", p); // p has the parameters
, но тогда я получаю следующее сообщение об ошибке:
DML statements are not supported on non-federated tables in a filtered connection.
ВТУ? Помните, моя таблица объединена. Кроме того, аналогичный код отлично работал с другими таблицами. Странная вещь о Stuff заключается в том, что ее схема недавно изменила LOT, поэтому мне кажется, что, может быть, я подключаюсь к члену федерации непосредственно в VS2012, и внесение изменений там каким-то образом не сделало его не объединенной таблицей (есть 3 типа таблиц в объединенная база данных: http://convective.wordpress.com/2012/03/05/introduction-to-sql-azure-federations/).
Итак, поскольку я нахожусь в разработке, в Stuff действительно нет ничего важного, поэтому я пошел дальше и скопировал его код CREATE TABLE и полностью отбросил его из этого члена, вернулся в корневую базу данных и повторно - выполнил приведенный выше код наверху с оператором FEDERATED ON (ClientId=cid), а затем повторно запустил инструкцию insert из моего приложения, и это сработало чудесно!
Так что, очевидно, что-то случилось, чтобы мой стол не был «объединен». В конце концов, мои вопросы довольно просты:
- Есть запрос, который я могу работать на корневой базе данных или, может быть, на члене федерации, чтобы сказать мне, какие таблицы являются федеративными и которые не являются?
- Кроме того, может ли кто-нибудь сказать мне, почему мой одноранговый стол больше не объединен? Потому что, очевидно, я могу внести изменения схемы в далеком будущем и не смогу просто отбросить стол, а начнется, так что было бы неплохо узнать, что я делаю неправильно.
Очень хороший вопрос. Именно тот, который я собирался спросить :) +1. – JYL