結局、これってミリ秒までマッチングする必要がないのなら、格納時に、
Dim hogeTime As DateTime = Now
じゃなく、
Dim hogeTime As DateTime = CDate(Now.ToString)
みたいにして、ミリ秒を削った時間（まあ、実際は 0ミリ秒になるってことだけど）をセットしてやれってことか。
こうすると、hogeTime には実際の時刻が 2014/09/04 18:37:36.5685248 であろうと、2014/09/04 18:37:36.0000000 という値がセットされるので、
dv.RowFilter = "hoge_time = #" & hogeTime & "#"
という条件でマッチングするようになる。
dv.RowFilter = "hoge_time >= #" & hogeTime.ToString & ".00000# Or hoge_time <= #" & hogeTime.ToString & ".99999#"
みたいに長ったらしい条件書かなくてもいい。
つーか、この長ったらしい条件、やっぱダメだよね。
例えば、これじゃあ 2014/09/04 18:37:36.9999999（小数点以下 7桁）の時間はマッチしないよね。条件が <= 2014/09/04 18:37:36.99999（小数点以下 5桁）だから。18:37:36.9999900 ってことだもんね。
いや、それは小数点以下の桁数を 7桁にして <= 2014/09/04 18:37:36.9999999 となるようにすればいいやん・・・と思うかもしれんけど、小数点以下の最大桁数って、これ、絶対固定なの？
今、仕事で使っている Windows 8.1 Pro（64bit）の VB.NET で確認すると、7桁まで取れるようなんだけど（ToString("yyyy/MM/dd HH:mm:ss.FFFFFFFF") みたいにミリ秒以下を 8桁にすると例外エラーで落ちる）、これ、32bit 版でも一緒なの？あるいは、今後 CPU のビット数や OS のバージョンが上がっても、絶対 7桁なの？12桁とかにならないの？
そのあたりが担保できない限り、やっぱミリ数は含めるべきじゃないよね。青天井で桁数増えていく可能性あるんだから。この辺、「Microsoft の勝手」の世界だよね？
今は <= 2014/09/04 18:37:36.9999999 が有効でも、何年か後はわからんってことよね。
ということで、時間は CDate(Now.ToString) して突っ込んじゃうのが一番安全そう。
「業務アプリケーション」でミリ秒まで必要なケースって糞レアだからな（笑）
コメントする