ADO.NET2.0のパラメータクエリ

一応%もパラメータクエリに渡せるみたいだ。
こんな感じ
using System;
using System.Collections.Generic;
using System.Text;
using System.Data.SqlClient;
using System.Data;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
string strConn, strSQL;
strConn = @"Data Source=.\SQLExpress;" +
"Initial Catalog=Northwind;Trusted_Connection=YES;";
strSQL = "select * from customers where companyname like @a";

SqlConnection cn = new SqlConnection(strConn);

cn.Open();
using (SqlTransaction txn = cn.BeginTransaction())
{
SqlCommand cmd = new SqlCommand(strSQL, cn, txn);
cmd.Parameters.AddWithValue("@a", "FA%");
SqlDataReader rdr = cmd.ExecuteReader();
while (rdr.Read())
Console.WriteLine("{0}", rdr.GetString(0));
rdr.Close();
txn.Rollback();

}
cn.Close();

int b;

}
}
}

Inside SQL Server2005の誤字報告の回答が来ました。

早い回答で。
１７個中９個が誤字で、８個が審議中とのこと。

３か月ぶりに床屋へ

床屋へ行ってきました。いつもの「サミット」です。シャンプー込の1900円。普段は待ち時間がないはずなのに今日は、混んでて10分ぐらい待たされた。で、シャンプー抜きと言ったつもりがなぜかシャンプーが始まりシャンプー込のメニューに。200円の違いなので反論せずになすがままに。えぇチキンですから。

また本を購入

まだ、ADO.NET2.0の本やインサイドSQL Server2005を読み終わっていないのに、SQL Server 2005 ストアドプログラミングの本は読むのをやめてしまったのに、またSQL Server2005の本をアマゾンで購入してしまいました。今回はオフィシャルマニュアルです。いつになったら手持ちの本が読み終わるんだか。

喉の痛みが治まらない

風邪をひいたかも。土曜日の朝から痛み出した喉が、今日になっても治まらない。
薬飲んだのに。睡眠時間を多少多めにしてみたのに。ブートキャンプお休みしたのに。

家庭用ではないスイッチングハブ

電源を入れるとファンがうるさい。
さてどう使おうか？
背面にRS232ポートがあるようだけどいろんな事が出来るのかな？
スパニングツリーとか、ミラー(モニタ)ポート化とか。。

SQL Serverって主キーをupdate出来るんですね。

SQL Server2005Expressで確認しました。
で、Inside SQL Server2005ストレージ編には、updateがdeleteとinsertに分解され、主キーの順でソートされるそう。
でもそれだと以下の③はうまくいかない気がする。
deleteを先にやろうとすると外部キー制約に引っ掛かるはずなのに引っかからない。なんか特別な処理をしているのかな？
USE [pubs]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[tbl](
[pk1] [int] NOT NULL,
[ux1] [int] NOT NULL,
CONSTRAINT [PK_tbl] PRIMARY KEY CLUSTERED
(
[pk1] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY],
CONSTRAINT [IX_tbl] UNIQUE NONCLUSTERED
(
[ux1] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[tbl2](
[num] [int] NOT NULL,
[rel1] [int] NULL,
CONSTRAINT [PK_tbl2] PRIMARY KEY CLUSTERED
(
[num] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[tbl2] WITH CHECK ADD CONSTRAINT [FK_tbl2_tbl] FOREIGN KEY([rel1])
REFERENCES [dbo].[tbl] ([pk1])
GO
ALTER TABLE [dbo].[tbl2] CHECK CONSTRAINT [FK_tbl2_tbl]
GO

insert tbl(pk1,ux1) values(1,10);
insert tbl(pk1,ux1) values(2,20);
insert tbl2(num,rel1) values(100,2);

select * from tbl2
--以下は一意性エラー
update tbl set pk1=2 where pk1=1;

--以下は正常
begin tran;
update tbl set pk1=3-pk1
select * from tbl
rollback;

--以下は一意性エラー
update tbl set ux1=20 where ux1=10;

--以下はok
begin tran;
update tbl set ux1=30-ux1;
select * from tbl
rollback;

--③以下もok
begin tran;
update tbl set pk1=3-pk1, ux1=30-ux1;
select * from tbl
rollback;


それはそうと、主キーが変えられるとなると昔作ったトリガの設計が破綻することになるのか。はぁ。
昔作ったトリガは効率化のために、insertedとdeletedのテーブルを主キーで連結し前後の変化列を調べて変化に見合う処理を行っていたのだけれど、主キーが変えられると変化を追跡できない。
効率を無視して、deletedテーブルでdeleteに見合う処理を行って、insertedテーブルでinsertに見合うを行うというようにdeleteとinsertの処理を別々に処理しなければならなかったのかな。（こちらの方が条件式のバリエーションが減るし。）