Visual Studio のデータ ソースまたは SQL 管理コンソール自体を介して、2 台目のコンピューター (両方のコンピューターとも Win7 64 ビットを実行) で実行されている SQL Server 2008 に接続しようとすると、奇妙な問題が発生します。
最初の接続試行ではタイムアウトになります。2 回目の試行では正常に動作します。
2 台目のコンピューターの共有には問題なくアクセスできますが、各アプリケーション インスタンスで SQL に接続しようとするのは初めてであるように見えます。つまり、2 つの Visual Studio インスタンスを開くと、最初の接続試行では両方とも失敗しますが、2 回目には成功します。各インスタンスに 2 回接続する必要があります (他のアプリケーションでの失敗/成功のシーケンスに関係なく)。
それが意味を成すといいのですが。
何かアドバイス？
答え1
解決策を見つけたと思います。少なくとも私の場合はうまくいっています。インスタンス名を使用しているため、SQL Server サービスの動的ポートが自動的に使用されます。設定を動的ポートから固定ポートに変更し、そのポートでファイアウォールを開きました。
SQL Server 構成マネージャー --> SQL Server ネットワーク構成 --> 'InstanceName' のプロトコル --> TCP/IP --> プロパティ --> IP アドレス --> IP すべて -->
ここでは 2 つのオプションが表示されます。
- TCP 動的ポート: 51250 (ランダムに生成)
- TCP ポート: 空 - ここでは 1433 を入力し、ファイアウォールを開きました (まだ開いていなかった場合)。任意のポートを入力できます (インスタンスが 1 つしかないため 1433 を入力しました。インスタンスが複数ある場合は、インスタンスごとに異なるポートを選択し、ファイアウォールで開く必要があります)
ポートを開く作業を簡単にするために使用されるスクリプトを MS からダウンロードし、ここで再現します (コメントはドイツ語ですが、明らかなはずです)。
@echo ========= Ports des SQL-Servers ===================
@echo Aktivieren von Port 1433 für die SQLServer-Standardinstanz
netsh firewall set portopening TCP 1433 "SQLServer"
@echo Aktivieren von Port 1434 für dedizierte Administratorverbindungen
netsh firewall set portopening TCP 1434 "SQL-Administratorverbindung"
@echo Aktivieren von Port 4022 für den konventionellen SQL Server-Service Broker
netsh firewall set portopening TCP 4022 "SQL-Service Broker"
@echo Aktivieren von Port 135 für Transact-SQL-Debugger/RPC
netsh firewall set portopening TCP 135 "SQL-Debugger/RPC"
@echo ========= Ports für Analysedienste ==============
@echo Aktivieren von Port 2383 für die SSAS-Standardinstanz
netsh firewall set portopening TCP 2383 "Analysedienste"
@echo Aktivieren von Port 2382 für den SQL Server-Browserdienst
netsh firewall set portopening TCP 2382 "SQL-Browser"
@echo ========= Verschiedene Anwendungen ==============
@echo Aktivieren von Port 80 für HTTP
netsh firewall set portopening TCP 80 "HTTP"
@echo Aktivieren von Port 443 für SSL
netsh firewall set portopening TCP 443 "SSL"
@echo Aktivieren des Ports für die Schaltfläche 'Durchsuchen' des SQL Server-Browserdiensts
netsh firewall set portopening UDP 1434 "SQL-Browser"
@echo Zulassen von Multicast-/Broadcastantwort auf UDP (Aufzählung der Browserdienste OK)
netsh firewall set multicastbroadcastresponse ENABLE
答え2
私の推測では、あなたは自動閉じるデータベースに対してオンになっています。つまり、接続時にデータベースを起動する必要があり、これが初期タイムアウトの原因となります。
2 つ目の推測は、ホスト名の解決に関連している可能性があります。つまり、最初のホスト名の解決に時間がかかりすぎます (ブロードキャストによる可能性があります)。その後、後続の接続試行でキャッシュされます。ホストの解決に何を使用していますか? DNS ですか? 接続文字列を IP、ポート形式に変更してみてください。例: 192.168.100.100,1433
また、接続試行が成功した後に実行してみて、同じ動作が得られるか確認することもできますipconfig /flushdns。危険な回避策は、HOSTS ファイルに検索を入れることですが、適切に修正する必要があります。
答え3
目隠しをして暗闇の中で遠くを狙っているような気がしますが、役に立つかもしれません。Microsoft SQL Developer フォーラムに、同じ問題と思われるものについて、考えられる解決策とともに説明した古いスレッドがあります。彼のサーバーは Windows Server 2008 を実行していますが、Win7 セットアップにも関係があるかもしれません。
スレッド：
スレッドより:
はい、この問題は修正しました。
私の Windows Server 2008 は、SASL LDAP バインドを拒否するように構成されていました (警告 2886 を参照)。
このようなバインドを拒否しないようにサーバーを構成したので、SQL Server 2008 の接続は正しく機能します。
LDAP 署名設定の変更に関する情報については、Microsoft KB 935834 を参照してください (私は新規ユーザーなのでリンクできません)。
それが役に立てば幸い！
答え4
VS または SSMS に初めて接続する前に、SQL Profiler を実行して、SQL Server で何が起こっているか確認してみませんか?
また、イベント ログをチェックして、何かが記録されているかどうかを確認しましたか?