VB.NETのイミディエイトウィンドウのインテリセンスが不安定?

ソリューションを開く、イミディエイトウィンドウを開く、入力してもインテリセンスは出ない。
ブレークポイントなど置いてステップイン、エディターがデバッグモードになるとインテリセンスが出る。
その後はデバッグ中止して、普通の状態でも出る。
一度ソリューションを閉じて開く、デバッグ開始しなくても出る。
もう一度閉じて開くと出なくなる。
IDE再起動はもちろん出なくなる。

シンボルをローカルに置いても同じ症状。
4Kモニターのスケーリングを変えても同じ。

あまり困ることはないけど気になります。
visual studio2019で win10でもwindows server2019でも同様です。 

VBAからExcelを操作2

前回の

この部分耐えがたい遅さです。
vb.netの二次元配列はまあまあ我慢できますがVBAはデータが多くなるとだめです。
一次元目の要素(項目数)が少なければ一次元配列を並べた方が速いです。
さらに速いのはレコードセットから直接ループさせつつ書き込む。
すごく速いのでvb.netもデータテーブルから直接書き込むようにしました。
プロセスも今の所残っていません。コードが冗長になりますけど。

vb.net から Excel を操作 2

前回の続きです。
excelを開いて、あるワークシートのコピーを最前列に追加、
適当なセルから順に配列の値を流し込んで保存して閉じる。

難しい

vb.net から Excel を操作

以前ここでExcel出力のことを書いたけど
裏技的で推奨できない。
正攻法で行くことにしました。
Excel参照設定もクライアント環境で違うでしょうから依存しない実行時バインディングで・・
excelのプロセスが残らないようにするのが大変でした
まずは単純に開いて5秒待って閉じるだけ

開いて閉じるだけでも変数が多くて混乱します
次に開いてセルに文字代入して保存して閉じる。

セルに代入するだけで変数が増えました。
これを踏み台にdatatableの数値を配列を使ってExcelのセルに代入する。

openrowsetで既存Excelファイルへexport

vb.netでSQLserverテーブルをクエリして既存excelファイルに出力

accessのVBAからなら
docmd.transferspreadsheet acexport,acspreadsheettypeexcel9,”クエリ”,”ファイルパス”
でしたがvb.netでは難しいです

SQLserverにはopenrowsetというクエリでexportできるようなのでvb.netからExecutenonqueryで操作

SQLserverで準備
SQLserverは64bitでaccess32bitがすでにインストされているのでACEの32bitが既存
SQLserverのリンクサーバに64bitのACEのプロバイダ登録が必要なので
https://knowledge.autodesk.com/ja/support/autocad/learn-explore/caas/sfdcarticles/sfdcarticles/JPN/How-to-install-64-bit-Microsoft-Database-Drivers-alongside-32-bit-Microsoft-Office.htmlを参照にACEの64bit版をちょっと強引にインスト

SQLserverのリンクサーバーにACE登録

SQLserverでmasterデータベースで以下クエリ発行
exec sp_configure ‘show advanced options’,1;
reconfigure;
exec sp_configure ‘ad hoc distributed queries’,1;
reconfigure;
exec sp_MSset_oledb_prop N’Microsoft.ACE.OLEDB.12.0′ ,N’AllowInProcess’,1;
reconfigure;
exec sp_MSset_oledb_prop N’Microsoft.ACE.OLEDB.12.0′ ,N’DynamicParameters’,1;
reconfigure;

exportするクエリは
insert into openrowset(‘Microsoft.ACE.OLEDB.12.0’,
‘Excel 8.0;DATABASE=ファイルパス;imex=0;hdr=1;’,
‘SELECT カラム FROM [excelのワークシート名$]’)
select カラム from sqlserverテーブル where 条件カラム=パラメータ

接続文字がとっても厳格、ここまで試行錯誤数日
vbaでは列名含めて新しいワークシートに出力できたが
openrowsetはワークシートと列名は作成しておく

クエリが問題なければvb.netからExecutenonqueryで出力

最初VB.NETのコードでゴリゴリとやっていたけど難しくて断念
openrowsetもかなり難しいし環境が違えば同様にはいかないだろうし後日再検討しよう

integer と long

VBAでは
integer -32768 から 32767
long  -2147483648 から 2147483647
vb.netでは
integer -2147483648 から 2147483647
long -923372036854775808 から 9223372036854775807

vbaで
dim i as long
for i=0 to ..
と書いていたがvb.netで同様に書くとなぜだかインテリセンスによく怒られる
vbaのlongはvb.netではinteger
今更だけど

datagridview iifエラー

VB.NETでdatagridviewをGUIで作成するとき
クエリに
select iif(bit型カラム=0,’男’,’女’) as 性別,…from sqlserverTable
と書くとエラー
select 性別=case when bit型カラム=0 then ‘男’ else ‘女’ end,…
と書くと大丈夫

VBAのレコードセットも癖が強いがVB.NETも一筋縄では行かない気がする

ちょっとベンチ

バックエンドSQLserverフロントエンドAccessVBA VS VB.NET
‘VBA
Public Function Queryspeedtest()
Dim T1 As Double
Dim T2 As Double
T1 = Timer
Dim cn As ADODB.Connection
Dim rs As ADODB.Recordset
Set cn = New ADODB.Connection
Set rs = New ADODB.Recordset

cn.ConnectionString = “OLEDB接続文字”
cn.Open
rs.cursorlocation=adUseClient
rs.Open “select A.code,B.codename from TableA as A inner join TableB as B on(A.code=B.code)”, cn, adOpenStatic, adLockOptimistic

rs.Close
cn.Close

T2 = Timer
Debug.Print T2 – T1
End Function

‘VB.NET
Public Shared Function Queryspeedtest()
Dim SW = New System.Diagnostics.Stopwatch()
SW.Start()

Dim cn = New System.Data.OleDb.OleDbConnection(OLEDB接続文字)
cn.Open()
Dim cmd = New System.Data.OleDb.OleDbCommand(
“select A.code,B.codename from TableA as A inner join TableB as B on(A.code=B.code)”, cn
)
Dim DT = New DataTable(“test”)
Dim adp = New System.Data.OleDb.OleDbDataAdapter(cmd)
adp.Fill(DT)
adp.Dispose()
cn.Close()

SW.Stop()
Debug.WriteLine(SW.Elapsed)
End Function

tableAは20万件、TableBは1万件弱のマスターファイル
TableAのレコードのcodeからTableBのcodenameを得るよくあるクエリ
もちろん主キーは両方あり

単純なselect column from tableは若干VBが勝利
上記のクエリはVBA 0.4s NET 0.8s

倍とはいえ差はコンマ数秒なのでまあいいかと思うがdatagridviewでtextbox表示とかcomboboxに入れたりするとちょっと・・
Accessフォームの方が速い、VB.NETではちょっと工夫が要りそうな

vbaでcursolocationがクライアントの時はcursoltype、locktypeによる差はない
サーバサイドでは最速と覚えていたadopenforwardonlyよりadopendynamicの方がなぜか早かった

ADODBとADO.NETはまったく別物なので比較するなと言われそうだけど・・
でもVSのエディタはすばらしい、VBAエディターが残念に思えるほど

datatable のクエリ

が遅い

sqlserverテーブルのシンプルな選択クエリ。
フォームに表示が遅いのではなく デザイナーで作成途中の確認の段階で遅い。

accessから移行中のクエリだがaccessのリンクテーブルのクエリの方がはるかに速い

ADODBのデータソースレス接続の様にコードにクエリを書いてdataadapter作成したほうが速いのか?

ODBC接続のaccessクエリに ADO.NETが速さで劣る?

どこか間違えているのかも、明日落ち着いて見直そう

datagridviewでキャレット位置取得

こちらはたいへんでした
Accessのように簡単にいきませんでした
あちこち調べて
On Error Resume Next

Dim TexteditCtrl As DataGridViewTextBoxEditingControl
TexteditCtrl = DirectCast(DataGridView1.EditingControl, DataGridViewTextBoxEditingControl)
Dim tb As DataGridViewTextBoxEditingControl = CType(TexteditCtrl, DataGridViewTextBoxEditingControl)
Dim startP As Long
Dim str As String
Dim strCount As Long
startP = tb.SelectionStart

str = “文字”
strCount = Len(str)

tb.SelectedText = str
tb.SelectionStart = startP + strCount

でなんとか取得して同位置に代入できますがキャレット位置はコマンドボタンのクリックイベントではできない
というかキャレットが消えてしまう
ここはAccessと同じです
なのでこれはラベルのクリックイベント ラベルのボタン加工はAccessよりはるかに難しい
VSも良いですがAccessの良さも再認識してます