4

BDE が廃止されようとしていた頃に開始された、ある程度のサイズ (約 1MLOC) のアプリケーションがあります。現在、ODBC を使用して SQL Server に接続するためにのみ使用しています。非推奨のステータスにもかかわらず、驚くほどうまく機能しており、さらに 15 年間機能し続ける可能性があります。ただし、それが機能しなくなるかどうか、いつ機能しなくなるかは誰にもわかりません。もしそれが止まってしまえば、エンバカデロはそれについて多くのことをすることができなくなります. これは時限爆弾なので、交換する必要があります。しかし、何と？

Delphi の ADO コンポーネントは有望に見えます。BDE コンポーネントに似たテーブル コンポーネントとクエリ コンポーネントがありますが、それらは興味を失う可能性のあるワンマン ショップによって作成されたサード パーティ製のコンポーネントではありません。不格好な ODBC-Administrator の代わりに接続文字列を使用することも楽しみにしています。

ただし、約 1 年前、Microsoft は OLE DB が非推奨であることを発表しました。ネイティブ開発には、SQL Server Native Client ODBC ドライバーを使用する必要があります。

それで、私の質問は、Delphi の ADO コンポーネントが OLD DB にハードワイヤードされているかどうかです。それとも、ドライバーのリストで "SQL Server Native Client" を選択した場合、OLE DB を使用していないのでしょうか?

SQL Server Native Client ODBC ドライバーを利用するには、現在行っているように、ODBC-Adminstrator でデータソースを設定する必要があると思います/恐れています。または、接続文字列を使用して ODBC に接続できますか?

また、OLE DB を使用せずに ODBC に接続できる Delphi コンポーネントは何ですか? はい、dbExpress については知っていますが、BDE から dbExpress に変換するには何年もかかるようです。

ありがとう、ランドシャーク

4

3 に答える 3

3

5 年前にも同様の移行のニーズがあり、かなりの調査とテストを行いました。BDE からの最も簡単な移行パスは、devart (http://www.devart.com/sdac/) から SDAC に移行することです。Devart には、コードを調べて BDE コンポーネントを同等の SDAC コンポーネントに置き換える BDE 置換ユーティリティがあります。約 90% の方法でそこにたどり着き、すべてを機能させるために手動でいくつかの変更を加える必要があります (たとえば、fetchall を使用する場合は、すべての fetchall コードをコメントアウトする必要がありますが、パターンが表示され、修正できます。残りのコードは、主に検索と置換によって行われます)。SDAC コンポーネントのパフォーマンスは優れており、すべての SQL サーバー呼び出しをサポートし、インターネット経由で暗号化された接続を使用できます。コンポーネントは、SQL Server へのネイティブ SQL または OLEDB 接続をサポートします。また、キャッシュされた更新を使用して分離モードで動作します。SQL サーバーに加えて他のデータベース プラットフォームをサポートする予定がある場合の別のオプションは、UniDac を使用することです。これは SDAC に似ていますが、SQL サーバー、Oracle などで動作します。オーバーヘッドのない古い BDE と非常によく似ています。

于 2012-10-11T15:20:53.600 に答える
2

1) 「ネイティブ接続」とは、ODBC や OLE DB、BDE や DBX の使用を意味するものではありません。ネイティブ接続とは、MS SQL にのみ接続でき、標準のサーバーに依存しないパイプラインを使用しない特別なライブラリを使用することを意味します。逆に、BDE と DBX、ADO と ODBC は、プラグインをインストールする任意のサーバーへの接続を提供する汎用ライブラリです。

通常、ネイティブ ライブラリは、サーバーとのより緊密な統合を提供し、ジェネリック ライブラリでは見逃される可能性のあるいくつかの機能 (firebird/interbase サーバーのイベントなど) を使用します。また、パイプラインのパブリック API 標準との間でデータ ストリームやコマンドをトランスコードする必要がないため、高速に動作することもできます。

パブリック インターフェイス OTOH は、サーバーの切り替えを容易にし、サーバーに依存しないアプリケーションの開発を容易にします。

2) BDE -> DBX 変換が BDE -> ODBC または BDE -> ADO または BDE-> なんでもよりも難しいと思うのはなぜですか? 変換は変換です。ADO にも、DBX やその他のライブラリと同様に、制限と落とし穴があります。

3) DBX には MS SQL プラグインがあります。DevArt は一連の DBX プラグインを提供しており、在庫の Delphi DBX MS SQL サポートよりも優れたプラグインを提供する可能性があります。またはそうでないかもしれません。

4) それらを除けば、よく知られているサーバーに依存しないライブラリはほとんどありません。

5) http://www.torry.net/pages.php?id=570のような任意のコンポーネント コレクター サイトで多くの直接 ODBC 接続を使用できます。

6) ネイティブの MS SQL 接続についても同じhttp://www.torry.net/pages.php?id=1513

ただし、これらの選択肢を評価して決定を下すには、自分だけが持つことができるコンテキスト内の知識が必要です。

于 2012-10-11T12:52:24.443 に答える
0

数年前にも同じ問題がありました。完璧な解決策があれば、それほど多くの選択肢はないと思います。

とにかく、BDE+ODBCからADO+SQLOLEDBに切り替えました。主な理由は、信頼性が高く、変換が簡単で、顧客のコンピューター（BDEなど）に追加のインストールを必要とせず、DBX（DisableControlsを使用する場合）を含むdelphiに付属する他のコンピューターよりも高速であったことです。

また、補足として、ODBCを使用して接続を構成する場合は、ODBCマネージャーを使用して値を構成できますが、レジストリから値を読み取り、ODBCなしで直接接続できます。それは私たちが切り替えを行うのに役立ちました。

于 2012-10-11T13:40:52.520 に答える