2

SQL Server からアクセスする必要がある Visual FoxPro テーブルがあります。Sql Server x86 では、リンク サーバーを作成するだけです。残念ながら、VFP 用の x64 ドライバーはありません。そのため、Sql Server x64 はそれにリンクされたサーバーを作成できません。

これまでのところ、次のオプションを思いつきましたが、どれも特に好きではありません。

  1. クエリが x64 -> x86 -> VFP から移動するように、x86 Sql Server をリレーとして使用するように設定します。

私は開発者であることに加えて、システム管理者でもあるので、これはあまり気にしません。したがって、これは、さらに別の Sql Server にパッチを適用し、維持し、監視する必要があることを意味します (別のインスタンスを使用するだけではない場合)。

また、VFP プロバイダーは 4 つの部分の構文では機能しないため、OPENQUERY を使用する必要があります。OPENQUERY ステートメントを別の OPENQUERY ステートメントに埋め込むために発生する必要があるすべての一重引用符のエスケープを考えると、頭が回転します....

  1. CLR テーブル値関数を作成しますが、アセンブリは (おそらく?) x64 でもあるため、実際にクエリを実行するには、proc (IPC? Webservice?) を実行する必要があります。

TVF にはスキーマが必要であることが判明したため、このオプションは最初に考えたほどクリーンではありません。私は、WCF クライアントを MSSQL に入れるためにスパイクを行いました。MSSQL は、Sql XML データ型関数で解析できる XML の単一の列を返します。それは機能し、実際には変数をパラメーターとして受け取るため、OPENQUERY よりもクエリに少し適しています。これにより、一重引用符と EXEC ダンスのほとんどを節約できます。

もちろん、Sql 内の WCF は完全にサポートされておらず、かなり大きなハックのような匂いがします。私は、パフォーマンスと信頼性に関してかなり深刻な懸念があります。

  1. Sql Server から VFP へのクエリの作成を停止し、かなりの量のクライアント コードを書き直します。

明らかに、これは「正しい」答えです。ただし、Sql Server テーブルと VFP テーブル間の結合に依存するクライアント コードがかなりあります。これを書き直して一時テーブルにデータを入力したり、クライアント側の結合を実行したりするのは、かなり大きな負担のようです。

誰かがより良い代替案、または同様の経験を提案できることを願っています.

4

2 に答える 2

2

それは厄介な問題です、私は同意します。

遅延に耐えられる場合は、SSIS を 32 ビット モードで実行して定期的に (おそらくオンデマンドで、同じ SP によってトリガーされるジョブで) SQL Server ネイティブ テーブルにデータをインポートすることもできます。これは、データ変更の頻度と、データがわずかに古い可能性があるという問題によって異なります。

于 2009-01-27T15:22:13.253 に答える
0

代替案を見つけたと思います。Microsoft は、Access 用の更新されたドライバーをリリースしました。これには、32 ビットと 64 ビットの両方のフレーバーがあります。元の Jet OleDB ドライバーと同様に、これにより、SQL Server x64 からdBase ファイル形式にアクセスできます。

唯一の制限は、DBF がISAM でサポートされている dBASE 形式のいずれかでなければならないことです。dBASE IV 形式を使用していくつかのテストを行ったところ、次の接続文字列を使用して動作するようです。

Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\folder;Extended Properties=dBASE IV;User ID=Admin;Password=;
于 2010-10-29T04:40:03.817 に答える