| タイトル | ： Re^3: 接続先のWindowsServerを64bitへ変更 |
| 記事No | ： 16501 |
| 投稿日 | ： 2019/08/23(Fri) 15:26 |
| 投稿者 | ： 魔界の仮面弁士 |
> ＜現状の接続文字列＞
> "Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;" & _
> "Initial Catalog=XXXXXSQL;Data Source=XXXXX-SERVER"
> となっております。
Windows 認証の接続文字列は、プロバイダによって微妙に異なる可能性があります。
https://docs.microsoft.com/ja-jp/dotnet/framework/data/adonet/connection-string-syntax
自分の場合、メインで携わっていたのは、SQL Server 2008 R2 (v10.5) の頃ですし、
手元にあるのも SQL Server 2014 (v12.0) まで(しかも利用権限が割り当てられていない)なので、
あまり具体的な話になると弱かったりしますが……SQLOLEDB での接続事例は見かけました。
http://www.jiging.com/WP/blog/2019/02/
汎用的な障害事例を見かけた場合は、むしろ情報提供をお願いしたいところ。
> の３点とも、「32bit版のモジュール」を 新たに クライアント端末側PCに
> 入れなければならない ということでしょうか？
SQLOLEDB はそもそも更新されていないため、既にインストールされている環境であれば、
アップグレードの必要は無いはずです。（Windows Update だけで十分かと思います）
それ以外のモジュールについても、「入っていなければインストールせねばならない」点は自明なので、
先述したとおり、クライアント上に *.udl ファイルを作るなどして、インストールされている
32bit ドライバーを事前確認しておくことをお奨めします。
> 実際にテストなどが出来なかったので、
> 「接続は引き続き可能」という情報ありがとうございます。
Windows Server も SQL Server も評価版が用意されていますので、
早めに環境(物理 or 仮想)を用意して、十分な検証工数を確保しておきましょう。
移植に際して、照合順序を古いものに合わせておくのかどうかとか、
互換性レベルは幾つに設定するのかといった点も検討しておく必要がありそうです。
> 推奨されていない SQLOLEDB をそのまま使い続けるという判断をした場合、
> 極論、クライアント側のアプリケーションの接続における記述などは
> 「何も変えなくて良い」ということになるのでしょうか？
厳しい言い方をするならば、そうは言えないと思います。
先に紹介したとおり、少なくとも下記の【重要】欄において、
SQLOLEDB および SQLNCLI は「非推奨のまま」であるとともに、
「新しい開発作業にはどちらの使用もお勧めできません」と、
わざわざ囲み枠として記載されているわけです。
その注釈の意味を考えると、自分ならば「何も変えなくて良い」という判断はなかなか下しにくいところ。
https://docs.microsoft.com/ja-jp/sql/connect/oledb/oledb-driver-for-sql-server
一方、楽観的な観測で言えば、SQLOLEDB をそのまま利用するとしても、
接続文字列の見直しだけで、そのまま動かすことができるであろうとも思います。
少なくとも下記の記述から、互換性は担保されているように見えます。
https://docs.microsoft.com/en-us/sql/connect/oledb/applications/support-policies-for-oledb-driver-for-sql-server
》 ADO support policies
》
》 ADO applications can use the SQLOLEDB OLE DB provider that is included with Windows
》 if they don't require any of the features of SQL Server 2005 (9.x) or later.
》
》 ADO applications can use the OLE DB Driver for SQL Server,
》 but if they do so they must specify `DataTypeCompatibility=80` in the connection strings.
》 Only features from SQL Server 2005 (9.x) are available
》 when `DataTypeCompatibility=80` is present in the connection strings.
》
ということで、実例を持たない自分の意見では何の回答にもなりませんが、
「何も修正しなくても間違いなく動く」あるいは
「接続文字列を変えただけで、以前と同様の動作となる」ことを、
誰かが利用者に保証できるのであれば、「何も変えなくて良い」と判断できそうです。
とはいえその保証をするのは、Microsoft でもなければ掲示板で回答している第三者でもなく、
作成したアプリをお持ちの、むろやさん自身しかありえないと思いますよ。
厄介な点として…先に紹介した URL にもありますように、既に SQLOLEDB のメンテンスは
打ち切られており、ODBC への移行が進められてきたという事実があります。
2011年夏の時点で既に非推奨扱いと明言されたのみならず、SQL Server 2017 においては、
そもそも OLE DB というテクノロジそのものが、非推奨とされています。
ところがその後の方針転換により、OLE DB の廃止案が撤廃され、
改めて MSOLEDBSQL がリリースされることになりました。
https://teratail.com/questions/36859
https://support.office.com/ja-jp/article/050d88f3-b2d6-4e76-b6f9-f3c556f139ea
こう何度も方針転換されてしまうと、開発者としてはたまったものではないですが、
安全策を取るなら、次のバージョンまでは保証されるが、次の次は分からないと考えて
その時々で推奨されている方式を採用することが望ましいと思っています、理想論的ですけれどね。
そうは言っても移行コストの問題もあるので、単純には行かないのが世の常ですし
あえて何もしないという判断が下される事例も少なからずあるでしょう。
ただ、Microsoft が SQLOLEDB を継続保守するのではなく、あえて MSOLEDBSQL として
再設計した意味を考えれば、サーバーリプレース案件において古い方式を使い続けることは、
リスクが大きい気がします。現時点での互換性については、十分に検討されているとは思いますが、
たとえばさらにその次の移行時において完全廃止されてしまえば、移行テストすら難しくなるでしょう。
互換性が担保されている今のうちに、接続方法の見直しを行うことも検討しておいた方が良いと思います。
（同様の問題として、Oracle Database 向けの接続ライブラリである oo4o が完全撤廃された問題で、
Oracle Client のバージョンを更新できなくなったという状況は、しばしば目にしてきました）
まぁ、そもそも VB6 のままで良いのかという問題もあるわけですが……それはまた別の話ですかね。
|