SQL Server / Oracleなど異種のRDBを使い分けるとき、 DBFactoryを使えば、コードは一つで済むので重宝していました。
テキストデータを使う普通のDataBaseアプリならば、特に問題はありませんでした。
今回、Oracleで LongRaw型の項目を扱ってみたのですが、うまく取れません。
LongRaw()型は遅延バインドモードで処理されているからでしょう。
取得するには、Oracle.Client を使い、 cmd.InitialLONGFetchSize パラメータをセットしてあげないといけませんでした。DEFactory()が使える範囲って、限定的なのですね。今後は使わなくなりそうです。
再度、考えてみました。DB関係のObject/Methodは多くあります。ADAPTERもその一つです。
ADAPTERは入門書にも登場するので使っている人は多いようですが、一考の余地はあります。
Adapter.Fill/Updateでの更新はお手軽で楽なのですが、冗長が目立ちます。
自動生成された更新用SQLは全項目のand 文が生成されています。commandBuilderでの生成でもそうですね。
必要な項目で更新SQLを作ったほうが効率が良いです。そんなこんなでADAPTERを使わなくなって久しいです。
con = New xxxConnection(ConnectString)
Dim cmd = New xxxCommand(sql, con)
cmd.ExecuteReader()
cmd.ExecuteNonQuery()
データベース関係はこの4つのステートメントで対処してます。DataTableも Load(DataReader)で取れれます。業務的には充分と考えてます。
ということは、ORACLE版、Access版,SQLServer版を作っても3 * 4 = 12のステートメントなので、DBFactory()を持ち出すメリットはますます薄れます。
そもそも、xxx_Clilentは個別のプロパティが多数存在するので、Factory Methodパターンを当てはめるのは無理があるのかも知れません。
便利なステートメントは副作用があるので、軽はずみに使うと、嵌りますね。