Office 2010 アップグレードとシステム要件

こんにちは、nagino です。

以下 Technical Preview 版の制限のため、今後変更される可能性があります。

アップグレードですが、以下のような記載がありました。

　32bit 版 2007 ⇒ 32bit 版 2010 は可能

　64bit 版 2007 ⇒ 64bit 版 2010 は不可能

2003 以前については言及がありませんが、おそらく不可能だと思われます。

・・・というか、Office は旧 Version との共存ができましたよね。（一部機能制限、挙動不安定などはありますが）

2010 と他の Version が共存できるかは確認してみたいと思います。

また、システム要件は以下のような記載がありました。（細かいところは割愛）

　HDD

　　2GB

　OS

　　Windows XP SP3 (32bit）

　　Windows Vista SP1 （32/64bit）

　　Windows Server 2003 R2 SP2 （32/64bit）

　　Windows Server 2008 SP1 （32/64bit）

　　Windows 7 （32/64bit）

　　Terminal Server and Windows on Windows（WOW） （64bit OS 上に 32bit 版 Office 2010）

　補足

　　システム要件や機能は、システムの設定や OS に依存する

やっぱり現時点では Win XP をサポートする OS に含めています。

さすがに Win 2000 は外れていますけどね。

しかし、Win XP 64bit 版はここでもなかったことになっていますね。

Win XP と Win 7 の環境で試してみたいと思います。

Office 2010

こんにちは、nagino です。

Office 2010 に関する情報が、アメリカの Worldwide Partner Conference で発表になりました。

私のところにも、今日 Office 2010 のベータの DL アドレスが送られてきまして、とりあえず英語の Read Me などに目を通しているところです。

今回は 32bit 版と 64bit 版があるのですが、64bit 版の方はメモリの使用可能量でアドバンテージがあるとのことです。

Windows Server も 64bit Only になりますし、クライアント側も 64bit 化が進んでいるようです。

ざっと見る限り、全製品揃っているようで、Visio まであります・・・、が、Project が無いですね。

Project は近々業務で触ることになりそうだったので興味があったのですが・・・残念。

前述の Conference でも言及があったようですし、FAQ ページなどには項目自体はあるので、製品としては開発が進められていると思われます。

まあ、今回のベータはかなり初期のベータなのでしょうがないところです。

でも、すでに日本語の Language Pack なども用意されているなど、なかなか素早い動きが伺われます。

さすがに会社の環境にインストールはできないので、自宅環境で使ってみたいと思います。

意外と知られていない基礎知識 その0 ・・・企画倒れかも？

こんにちは、nagino です。

しばらくは Microsoft Project Server の運用保守がお仕事になりそうで、開発や SQL Server からはサヨウナラしそうな nagino です。

はい。

さて、なぜか最近アクセスが多いのでアクセス履歴を見返していたのですが、検索キーワードで PASSJ 関連が目立ちますね。

日本では PASSJ が SQL Server 関連で断トツの大コミュニティーだっただけに、いざ休会してみると代わりとなるコミュニティーが見当たらないのですよね。

# 私も現在は VSUG ぐらいしか参加していませんので、ちょっとコミュニティを探していたりします。

PASSJ Blog まで閉鎖されてしまったので、SQL Server の基礎知識に関する情報がずいぶんとネットから減ってしまったように感じます。

もちろん SQL に関する情報は非常に多いのですが、たとえば以下のような情報です。

● SQL Server の各サービスの機能と役割

● SQL Server のプロトコル

● 照合順序

● ログイン、ユーザー、スキーマ、所有者

・・・etc.

・・・見返してみると、どれもネット上に情報はありますね。

改めてここでどうこうする必要は無いような気がしてきました。

「意外と知られていない基礎知識」は企画倒れになりそうです。

はい。

実はもうひとつ別案があります。

SQL Server の実行エンジンの物理操作・論理操作（Clusterd Index Scan など）について、それぞれどのようなモノか確認し、実行計画を読み解けるようになる、というものです。

でもこちらはかなりマニアックな内容になりそうなのと、私も全てを把握できていないのでどこまで行けるのかという不安もあります。

ちょっと次の方針を決めかねています。

Microsoft Project についてあれこれ書き始めるかもしれません。

うーん。

自動拡張

こんにちは、PASSJ 休会ということでションボリな nagino です。

PASSJ Blog も閉鎖されてしまいますので、今後は基本的な事項を概観するような内容をここで触れていこうかと思います。

なぜか「自動拡張」というキーワードで検索・訪問されている方が多いようです。

通常自動拡張や自動圧縮は、初期に適切に設定を行えばトラブルを起こすような機能ではないので、なぜキーワードで目立つのか分からないのですが、簡単に概観してみます。

自動拡張自体は単純な機能でして、データベースの領域を使い切って不足したら、領域を自動的に拡張するという機能です。

対になる機能として、自動圧縮というのもあります。

デフォルトでは自動拡張が有効、自動圧縮が無効になっています。

自動拡張が行われる際はディスク IO 等による負荷が発生しますので、通常はあらかじめデータファイルのサイズを大きく確保し、且つ自動拡張のサイズは固定値である程度大きめの値とすることが多いようです。

自動拡張のサイズが小さいと、データファイルのフラグメンテーションが発生しやすいことや、大量のデータを追加するような処理で自動拡張が繰り返し行われてパフォーマンスが極度に劣化するのを避ける狙いがあります。

また、拡張サイズを可変値（現在のサイズに対する割合）に設定すると、データベースが大きくなってきた際に拡張サイズが極端に大きな値となってしまい、自動拡張のタイムアウトによるエラーや、拡張するだけのディスク容量の不足によるエラーが発生してしまいますので、固定値とすることが多いようです。

自動圧縮は、自動拡張と同様に負荷が発生しますし、圧縮した分将来的に再拡張される可能性を考えて、通常は無効のままとするのがお勧めです。

自動圧縮しないとディスクが不足するようであれば、ハードの性能不足ということですので、ディスクの追加を検討すべき状況であるといえます。

sqlserver 文字列 比較 末尾 空白

こんにちは、nagino です。

うちのブログは宣伝無し、会社には秘密、なので、ほぼほぼ検索サイト経由の来訪のみだったりします。

で、タイトルのキーワードでの検索がちょっと目立ったので、以下まとめです。

# ちなみに、「SQLServer」ではなく、「SQL Server」が正式な名称です。

SQL Server で文字列型に対する末尾の空白については、以下のような動作をします。

※ 空白は分かり難いので、以下ではアンダースコア「_」で空白を表記します。

● char 型 / nchar 型

列のサイズになるまで、末尾を空白文字で埋めます。

char(3) に対して 'A_' を入れても、'A__' となります。

● nvarchar 型

末尾の空白文字は、指定したとおりに入ります。

nvarchar(20) に対して 'A_' を入れると、'A_' が入ります。

自動的に切り捨てられたりはしません。

● varchar 型

ANSI_PADDING が ON （デフォルト）の場合は、末尾の空白は指定したとおりに入ります。

varchar(20) に対して 'A_' を入れると、'A_' が入ります。

自動的に切り捨てられたりはしません。

ANSI_PADDING が OFF の場合は、末尾の空白は切捨てられます。

varchar(20) に対して 'A_' を入れると、'A' が入ります。

参考 URL

http://msdn.microsoft.com/ja-jp/library/ms187403.aspx

ですので、可変長文字列である varchar 型や nvarchar 型では、実はデータとしては末尾の空白を保持しているのです。

しかし注意すべき仕様が、比較処理の際の動作にあります。

文字列を比較する際は、末尾の空白を無視して比較処理が行われます。

'A' と 'A_' を比較する場合、'A' と 'A' として比較されます。

参考 URL

http://msdn.microsoft.com/ja-jp/library/ms191529.aspx

ですので、ともすると可変長文字列は格納時に末尾の空白が切り捨てられているように誤解されることも多くあります。

さて、これで終わっても良いのですが、これだと空白の有無も含めて比較したいケースで困ります。

その場合は、比較する前にバイナリ型に変換する必要があります。

CONVERT(varbinary, column-name)

これで比較すれば、空白の文字数も含めて厳密に区別されます。

なお、文字列長を比較に含めれば良いという話もありますが、改行文字や制御文字が含まれているケースを考えると、バイナリ型に変換するほうがお勧めです。

というのも、末尾に空白、改行（CR）、改行（LF）のどれか 1 文字がある場合に、区別がつきません。

例えば、以下のようなケースで長さ 2 のケースの区別がつきません。

SELECT

DATALENGTH('a' + ' '), -- 2
DATALENGTH('a' + char(10)), -- 2
DATALENGTH('a' + char(13)), -- 2
DATALENGTH('a' + char(10) + char(13)), -- 3
LEN('a' + ' '), -- 1
LEN('a' + char(10)), -- 2
LEN('a' + char(13)), -- 2
LEN('a' + char(10) + char(13)) -- 3

まあ、空白を無視しない比較演算子、ないしはオプションのようなものがあれば良いのですけれども、無いものはしょうが無いので、このような手間がかかります。