VSTO上のボタン類の制限
こんにちは、naginoです。
VSTO で、Excel のシートなどにボタンなど Windowsコントロールを配置して、クリックしたら実行、というのを作っていたのですが、ワークシートのズームが100%でないと動作しませんでした。
エラーメッセージは以下の通り。
文書が拡大または縮小表示されているため、Windows フォーム コントロールは無効にされています。ズームが 100% に戻されると、コントロールは再度アクティブになります。
下記にあるように、仕様ということになってしまうようです。
http://msdn.microsoft.com/ja-jp/library/ms178765(VS.80).aspx
回避策がぱっと思いつかず、どうしたものか。
Excel上でコントロールツールボックスにあるボタンを貼り付けて、マクロから .NET を呼び出すぐらいでしょうか。
ちょっと納期が近々の現状では今からさらに新しい仕組みや技術は組み込みたくなくて、困りました。
いまさらVBAは書きたくないところです。
まだ VSTO は色々と制限が多そうです。
面白いソリューションだけに、悩ましい。
VSTO 他のシートのコードの呼び出し
こんにちは、naginoです。
Java&JavaScriptの開発に関わりながら、Accessのツールの保守と、C#での開発をしつつ、現在VB.NETでVSTOの開発中という、言語が入り混じった状況で手一杯です。
さて、VSTOです。
目下VSTOの開発が一番直近の締め切りのため、必死です。
ユーザがパラメータをあるシートに入力し、ボタンを押すと、パラメータに合致するデータをAccessのDBから取得し、他のシートに表・グラフで表示する、というレポート系のツールを開発中です。
VSTOは初めて扱うので、右も左もわからなかったのですが、AccessのDBからデータを貼り付けるところまではOLEDBを使って出来ました。
ですが、DataTableからデータを単純にセルに貼り付けるうまい方法が思いつかず、結局ループで処理してしまいました。
なお、OLEDBの処理に関わるオブジェクトの後処理までちゃんとしている(はず)です。
もちろん、この後DB接続に関する部分は別クラスにまとめる予定です。
01: Friend Sub LoadData(ByVal connString As String)
02: Using conn As New OleDbConnection(connString)
03: Try
04: conn.Open()
05: Dim dt As New DataTable()
06:
07: Using cmd As New OleDbCommand()
08: cmd.Connection = conn
09: cmd.CommandText = "クエリ"
10: cmd.CommandType = CommandType.Text
11: Using sda As New OleDbDataAdapter(cmd)
12: sda.Fill(dt)
13: End Using
14:
15: Dim i As Integer
16: For i = 0 To dt.Rows.Count - 1
17: Globals.Test01.Cells(i, 1) = dt.Rows(i)("列1") 'ここでデータをセルに貼り付け
18: Globals.Test01.Cells(i, 2) = dt.Rows(i)("列2") '美しくない
19: Globals.Test01.Cells(i, 3) = dt.Rows(i)("列3") 'まるでASP/VBScriptのよう
20: Next
21:
22: End Using
23: Finally
24: conn.Close()
25: End Try
26: End Using
27: End Sub
アクセスレベルがFriendなのは、他のシートに紐付くビハインドコードから呼び出すためです。
呼び出し方がなかなか解らず苦労したのですが、、同一のnamespace内のときは、たとえば以下で対応していますが、果たしてこれが正しいのかどうかも不明です。
Globals.シート名.LoadData("接続文字列")
このあたりの単純な情報さえ、なかなかまとまったドキュメントが見当たらず、苦労しています。
ビルド番号とSPの対応
SQL Server 2005、2000、7、6.5です。
SQL Server のビルド番号は以下のクエリですぐ分かります。
SELECT @@VERSION
ですが、ビルド番号がどのサービスパック(SP)に相当するのかが、すぐには分かりません。
これらはKBにあります。
http://support.microsoft.com/?scid=kb;ja;321185
なお、特に SQL Server 2005 SP2 以降のビルド番号については以下のKBに詳しくあります。
http://support.microsoft.com/kb/937137/ja
ログインとユーザ
SQL Server 2005、2000、7.0です。
たぶん6.5や2008も同じですが、未確認です。
SQL Serverのアカウント管理には、ログインとユーザがあります。
ユーザについては、データベースユーザと呼ばれることもあります。
この2種類の関係が理解できず、設定が脆弱になっているサーバを良く見かけます。
ログインというのは、SQL Serverサービスのインスタンスに対する認証です。
一方でユーザというのは、DBに対する認証です。
ですから、ログインのみ作成してユーザを作成しないと、サーバには繋がるがクエリが実行できない、などという事態になります。
また、ユーザのみ作成してログインを作成しないと、サーバに繋がらない事態になります。
適切なユーザと適切なログインを作成し、ユーザーマッピングで紐付ける必要があります。
ただ、通常は両方セットで作成しますし、ログインとユーザには同じアカウント名を使用することが多いため、あまり意識されないようです。
意識されないからこそ、いざ必要なときにトラブルになります。
ちなみに、ログインのみを作成してユーザを作成しない場合、ユーザとしてはデフォルトでguestのみにマッピングされます。
その場合、デフォルトではmodel以外のシステムデータベースではguestが有効なため、それらのDBにのみ接続できます。
逆に接続先DBや規定のDBの設定がユーザの権限が無いDBの場合、接続時に規定のデータベースが開けない旨のエラーでログインに失敗します。
上記を理解した上で、ログインとユーザの権限をそれぞれ適切に設定する必要があります。
が、それらはまた長くなりますので、機会があればその時に。
文字列の比較における、末尾の空白の扱い
SQL Server 2005、2000、7.0です。
SQL Serverで文字列の比較を行った場合に、文字列の末尾の空白がトリムされます。
たとえば以下のクエリではtrueが表示されます。
IF 'abc' = 'abc '
SELECT 'true'
ELSE
SELECT 'false'
てっきり照合順序によると思っていたら、Japanese_BIN、Japanese_BIN2でもトリムされました。
よくよく調べてみると、2000と7.0については、SQL-92でそのように定義されているからそうなってる、とのKBがありました。
http://support.microsoft.com/kb/316626/en-us
では2005は、というとMSDN内にありました。
http://msdn.microsoft.com/ja-jp/library/ms191529.aspx
というわけで、照合順序は無関係でした。
今回は必要なかったのでここまでですが、上のKBの方のURLを見る限り比較検索条件に限る話ではないようですので、必要になればまた別途調べます。