giip
SES Proposal
SQL ServerLinked Server接続エラーバージョン互換性障害対応

Causes and Checks for Msg 7356 on a Linked Server in SQL Server

公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13

結論

Msg 7356 means "the linked server's OLE DB provider returned inconsistent metadata for a column." A distributed query asks the provider for each column's type, length, and nullability twice — once at compile time and again at run time — and this error fires when the two answers disagree. Typical causes include a changed view definition on the remote side, text-type or computed columns, and a heterogeneous provider that returns different metadata per row. Pass-through queries such as `OPENQUERY` are an effective workaround.

この文書の適用条件

対象製品SQL Server (distributed queries via a linked server)
確認バージョンSQL Server 2008 and later (message number 7356 is broadly common; provider-specific behavior needs verification)
適用環境On-premises, EC2, Amazon RDS (RDS has restrictions on linked server availability — verify)
必要権限Checking the configuration requires VIEW ANY DEFINITION or sysadmin. Changing linked server or provider options requires ALTER ANY LINKED SERVER or sysadmin
実行影響The check commands are read-only. Changing provider options affects every linked server on the instance
再起動Depending on the provider option, a restart of the SQL Server service may be required (verify)
最終検証日2026-08-13

そのまま実行できるコマンド

Check the linked server's configuration (read-only)参照のみ
対象
SQL Server 2008 and later
権限
VIEW ANY DEFINITION or sysadmin
変更作業
None (read-only)
Production実行
Safe to run
-- 対象: SQL Server 2008 以降
-- 権限: VIEW ANY DEFINITION または sysadmin
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    s.server_id,
    s.name,
    s.product,
    s.provider,
    s.data_source,
    s.catalog,
    s.is_linked,
    s.is_remote_login_enabled,
    s.is_rpc_out_enabled,
    s.is_data_access_enabled,
    s.is_collation_compatible,
    s.uses_remote_collation,
    s.collation_name,
    s.lazy_schema_validation,
    s.modify_date
FROM sys.servers AS s
WHERE s.is_linked = 1
ORDER BY s.name;
GO

-- 従来型の確認用ストアドプロシージャ
EXEC sp_helpserver;
EXEC sp_linkedservers;

The `provider` column shows which OLE DB provider is in use (`SQLNCLI11`, `MSOLEDBSQL`, `MSOLEDBSQL19`, `MSDASQL`, etc.). If you are still on an old provider, its metadata handling may differ from current versions. `is_rpc_out_enabled` needs to be on to use `EXEC ... AT`.

A four-part-name distributed query (the classic pattern that triggers 7356)参照のみ
対象
SQL Server 2008 and later
権限
The linked server's login mapping, and read permission on the remote side
変更作業
None (read-only)
Production実行
Safe to run (used to reproduce the error)
-- 対象: SQL Server 2008 以降
-- 権限: リンクサーバーのログインマッピングとリモート側の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能(エラー再現の確認用)
-- この形式ではローカル側がリモートのメタデータを取得してプランを作るため 7356 が起きやすい
SELECT col1, col2
FROM [LEGACY-SQL01].[SampleDB].[dbo].[SampleTable];

In a four-part-name distributed query, the local SQL Server fetches the remote side's column metadata before building an execution plan. When this "metadata fetched at compile time" disagrees with "the metadata the provider returns at run time," you get Msg 7356. First confirm whether the error reproduces in this form.

Switch to a pass-through query (the most practical workaround)参照のみ
対象
SQL Server 2008 and later (`EXEC ... AT` requires RPC OUT to be enabled)
権限
The linked server's login mapping, and read permission on the remote side
変更作業
None (read-only)
Production実行
Safe to run
-- 対象: SQL Server 2008 以降(EXEC ... AT は RPC OUT が有効であること)
-- 権限: リンクサーバーのログインマッピングとリモート側の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
-- 1) OPENQUERY: リモート側でクエリを実行し、結果セットだけを受け取る
SELECT col1, col2
FROM OPENQUERY([LEGACY-SQL01],
    'SELECT col1, col2 FROM SampleDB.dbo.SampleTable WHERE col1 > 0');

-- 2) EXEC ... AT: 完全なパススルー(RPC OUT が必要)
EXEC ('SELECT col1, col2 FROM SampleDB.dbo.SampleTable WHERE col1 > 0')
     AT [LEGACY-SQL01];

-- 3) 型が曖昧な列はリモート側で明示的にキャストする
SELECT note_column
FROM OPENQUERY([LEGACY-SQL01],
    'SELECT CAST(note_column AS nvarchar(4000)) AS note_column
       FROM SampleDB.dbo.SampleTable');

With a pass-through query, the remote side executes the query and the local side simply receives the result set. This reduces the back-and-forth of column metadata, and often avoids 7356. Using `EXEC ... AT` requires enabling RPC OUT on the linked server.

Reconcile the remote-side view definition (sp_refreshview)
対象
SQL Server 2008 and later (run on the remote server)
権限
ALTER permission on the target view, on the remote side
変更作業
Yes (regenerates the view metadata and forces dependent plans to recompile)
Production実行
Can be run, but causes a recompile of anything that references the view
-- 対象: SQL Server 2008 以降(リモートサーバー側で実行する)
-- 権限: リモート側で対象ビューへの ALTER 権限
-- 変更作業: あり(ビューのメタデータ再生成・依存プランの再コンパイル)
-- Production 実行: 可能。ただし再コンパイルが発生するため時間帯を選ぶこと
USE [SampleDB];
GO
-- 基になるテーブルの列変更に追随できていないビューを再整合させる
EXEC sys.sp_refreshview N'dbo.SampleView';
GO

-- 影響を受けそうなビューを洗い出す(参照のみ)
SELECT
    SCHEMA_NAME(v.schema_id) AS schema_name,
    v.name                   AS view_name,
    v.modify_date
FROM sys.views AS v
WHERE v.is_ms_shipped = 0
ORDER BY v.modify_date DESC;

A remote-side view that has not kept up with a column change (a type change, a new column) on its base table is a classic cause of Msg 7356. Views containing `SELECT *` are especially prone to drifting out of sync. Judge whether this fix applies based on whether there is a history of column changes on the remote side.

Set SET NOCOUNT ON in the remote procedure
対象
SQL Server 2008 and later (run on the remote server)
権限
ALTER permission on the target procedure, on the remote side
変更作業
Yes (changes the definition of the stored procedure)
Production実行
Apply according to your change management process
-- 対象: SQL Server 2008 以降(リモートサーバー側で実行する)
-- 権限: リモート側で対象プロシージャへの ALTER 権限
-- 変更作業: あり(ストアドプロシージャの定義変更)
-- Production 実行: 変更管理の手順に従うこと
USE [SampleDB];
GO
ALTER PROCEDURE dbo.SampleProcedure
AS
BEGIN
    -- 行カウントメッセージが余分な結果として扱われるのを防ぐ
    SET NOCOUNT ON;

    SELECT col1, col2
    FROM dbo.SampleTable
    WHERE col1 > 0;
END;

When calling a procedure across a linked server, row-count messages can be treated as an extra result set, interfering with determining the result set's structure. `SET NOCOUNT ON` is a general-purpose recommendation, and may not be the direct cause of 7356 — treat it as a fix to try and check for improvement.

Change a linked server option (affects the target linked server)
対象
SQL Server 2008 and later
権限
ALTER ANY LINKED SERVER or sysadmin
変更作業
Yes (changes the behavior of all queries through the target linked server)
Production実行
Can be run, but affects every process using that linked server
-- 対象: SQL Server 2008 以降
-- 権限: ALTER ANY LINKED SERVER または sysadmin
-- 変更作業: あり(対象リンクサーバー経由の全クエリに影響)
-- Production 実行: 可能。ただし影響範囲は当該リンクサーバー全体
-- EXEC ... AT を使うために必要
EXEC sp_serveroption @server = N'LEGACY-SQL01', @optname = N'rpc out', @optvalue = N'true';

-- スキーマ検証の遅延(コンパイル時のスキーマ確認を省く)
-- 効果は環境依存。検証環境で挙動を確認してから適用すること
EXEC sp_serveroption @server = N'LEGACY-SQL01', @optname = N'lazy schema validation', @optvalue = N'true';

-- 変更結果の確認
SELECT name, is_rpc_out_enabled, lazy_schema_validation
FROM sys.servers
WHERE name = N'LEGACY-SQL01';

`lazy schema validation` skips schema validation at compile time. It is a setting worth considering for schema-change-related errors in general, but whether it helps with Msg 7356 specifically depends on the cause. Treat it as a hypothesis to verify in a test environment before applying.

Change an OLE DB provider option (affects the whole instance)
対象
SQL Server 2008 and later
権限
sysadmin
変更作業
Yes (affects every linked server using the same provider)
Production実行
Not allowed as a rule. Requires verification in a test environment and agreement on the scope of impact
-- 対象: SQL Server 2008 以降
-- 権限: sysadmin
-- 変更作業: あり(同じプロバイダーを使うインスタンス上の全リンクサーバーに影響)
-- Production 実行: 原則不可。検証環境で確認し、影響範囲の合意を得てから実施すること
-- プロバイダー名は sys.servers の provider 列で確認した値を使う
EXEC master.dbo.sp_MSset_oledb_prop N'MSOLEDBSQL', N'AllowInProcess',      1;
EXEC master.dbo.sp_MSset_oledb_prop N'MSOLEDBSQL', N'DynamicParameters',   1;

Provider options affect every linked server on the instance that uses the same provider. Depending on the setting, a restart of the SQL Server service may be required, so check the behavior on the target environment before applying. Record the prior values so you can roll back before doing this.

結果の読み方

意味確認するポイント
providerName of the OLE DB provider in useWhether you are still on an old provider (the SQLNCLI family)
productName of the linked productWhether it is a heterogeneous data source other than SQL Server — such providers return metadata differently
data_sourceConnection targetWhether it points to the intended server/instance
is_rpc_out_enabledWhether RPC OUT is enabledMust be 1 to use `EXEC ... AT`
is_data_access_enabledWhether distributed queries are allowedIf 0, four-part-name access itself is not possible
lazy_schema_validationWhether schema validation is deferredThis setting can affect behavior — if changing it, verify in a test environment
is_collation_compatible / uses_remote_collationHandling of collationA check point if you are seeing problems with string comparison or conversion
modify_dateLast modification time of the linked server definitionWhether this coincides with when the error started occurring

こういう状況で使います

  • A query through a linked server fails with Msg 7356, "inconsistent metadata was provided"
  • The same query sometimes succeeds and sometimes fails, with no stable reproduction condition
  • A four-part name fails, but rewriting it as `OPENQUERY` succeeds
  • Errors started appearing right after a view or table was changed on the remote side
  • It only fails when a specific column (text-type, computed, or an aggregation result) is included

考えられる原因(可能性の高い順)

  1. 01

    The provider returns different metadata at compile time versus run time

    This is the essence of Msg 7356. SQL Server asks the provider for a column's type, length, and nullability when compiling a distributed query, and checks the same information again at run time. This error occurs when the two disagree. The items below are specific patterns that cause this.

  2. 02

    The remote-side view definition has not kept up with a change to the base table

    A view containing `SELECT *` can retain stale metadata even after a column change on its base table. Reconciling it with `sp_refreshview` can resolve this.

  3. 03

    The query includes text-type, computed, or expression-derived columns

    Legacy large-object columns like `text` / `ntext` / `image`, computed columns, or columns produced by an expression on the remote side can fail to return a deterministic length or type. Casting them explicitly on the remote side stabilizes this.

  4. 04

    A heterogeneous provider returns different metadata per row

    Some implementations of non-SQL-Server data sources (including `MSDASQL` over ODBC) return different metadata row by row. In this case, the basic policy is to handle it via pass-through rather than a distributed query.

  5. 05

    A remote procedure returns multiple result sets or row counts

    When calling a stored procedure, row-count messages or a conditional branch producing a different result set can interfere with determining its structure. `SET NOCOUNT ON` combined with a design that always returns a single result set can help (this is a hypothesis that needs verifying on the target environment).

  6. 06

    The provider version is outdated or inconsistent across connections

    Environments still using an old SQL Server Native Client can behave differently from current providers. Updating the provider can resolve this, but the update itself affects other connections, so it needs verification.

確認手順

  1. 1

    Check the linked server's configuration and provider

    参照のみ

    Check `provider`, `product`, `is_rpc_out_enabled`, and so on in `sys.servers`. Read-only.

  2. 2

    Check whether it reproduces with a four-part name

    参照のみ

    Minimize the failing query to identify which column triggers the error.

  3. 3

    Rewrite as `OPENQUERY` and compare behavior

    参照のみ

    If the pass-through version succeeds, you can conclude the cause lies in the local-side metadata-fetch step.

  4. 4

    Remove the suspect columns one at a time to isolate the cause

    参照のみ

    If excluding a specific column makes it succeed, that column's type or definition (computed, text-type, or via a view) is the cause.

  5. 5

    Check the change history of remote-side objects

    参照のみ

    Check `modify_date` in `sys.views` / `sys.objects` to see whether it lines up with when the error started.

  6. 6

    Run it standalone on the remote side to confirm success

    参照のみ

    Connect directly to the remote server and run the same query to confirm it succeeds on its own.

対応方法

すぐに実施できる低リスクの対応

  • Rewrite as `OPENQUERY` / `EXEC ... AT`

    参照のみ

    Having the remote side execute the query and returning only the result reduces the round-tripping of column metadata. This requires no configuration change and has a limited scope, making it the first thing to try.

  • Explicitly cast the problem column on the remote side

    参照のみ

    Fixing the type and length, e.g. `CAST(col AS nvarchar(n))`, stabilizes the metadata returned.

  • Replace `SELECT *` with explicit column names

    参照のみ

    Specifying only the columns you need can sidestep a problematic column.

事前検討が必要な変更

  • Reconcile the remote-side view

    Use `sp_refreshview` to regenerate the view's metadata. Effective when the view has not kept up with a column change on its base table.

  • Add `SET NOCOUNT ON` to the remote procedure

    A general-purpose fix for stabilizing the structure of the result set. Its effect depends on the environment, so verify whether the issue still reproduces after applying it.

  • Migrate legacy large-object columns to current types

    Migrate `text` / `ntext` / `image` to `varchar(max)` / `nvarchar(max)` / `varbinary(max)`. This is a schema change, so it requires an application-side impact assessment.

  • Update the provider to a current version

    Migrate from the old SQL Server Native Client to a current OLE DB driver. This affects other connections too, so it requires verification in a test environment and a staged rollout.

再起動・サービス影響を伴う変更

  • Change a linked server option

    A change such as `lazy schema validation` affects the behavior of everything using that linked server. Its effect depends on the environment, so this assumes verification in a test environment.

  • Change an OLE DB provider option

    This affects every linked server on the instance using the same provider, and may require a service restart. Record the prior values so you can roll back before doing this.

  • Reconsider the linked-server approach itself

    専門家レビュー必須

    For a heterogeneous data source where metadata inconsistency happens persistently, switching to an ETL or integration platform instead of a linked server is the root-cause fix. This is a design change.

!注意事項

  • Msg 7356 has multiple possible causes, and which one applies depends on the environment. Among the fixes in this article, `sp_refreshview`, `SET NOCOUNT ON`, and `lazy schema validation` are "hypotheses to try and verify" — they are not guaranteed to help.
  • Changing a provider option via `sp_MSset_oledb_prop` affects every linked server on the instance using the same provider. Depending on the setting, it may require restarting the SQL Server service.
  • Enabling `lazy schema validation` skips schema validation at compile time. Because detection of schema changes can be delayed as a result, apply it only after understanding this side effect.
  • When changing a linked server's authentication settings, also check the remote-side login mapping and permissions. Authentication-related changes can break other integrations.
  • Amazon RDS for SQL Server has restrictions on using linked servers. Check the target environment for whether creation is allowed and which providers are supported.

バージョン・環境による違い

SQL Server 2008 and laterMessage number 7356 along with `sys.servers` / `sp_serveroption` / `sp_refreshview` are available consistently. Fine-grained behavioral differences between providers vary by version, so verify on the target environment.
Provider generationsSQL Server Native Client (SQLNCLI / SQLNCLI11) is no longer recommended for new development. The current generation is the Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL / MSOLEDBSQL19). When migrating, also watch for differences in connection-string default behavior.
Amazon RDS for SQL ServerWhether a linked server can be created and which providers are available depends on the service specification (verify before relying on this).

これで解決しない場合に確認すること

  • Change history of remote-side object definitions

    Check `modify_date` in `sys.objects` / `sys.views` for a correlation with when the error started.

  • Trim the query down to a minimal repro to pinpoint the condition

    Remove columns one at a time to determine which one triggers the error.

  • Collation and string types on the remote side

    Between environments with different collations, string-type handling can trigger a separate, co-occurring error.

  • The error log and ring buffer

    Check the SQL Server error log for connection errors or provider-related messages logged at the same time.

この文書の根拠と限界

製品の公式ドキュメントに基づく説明

Based on the public specifications of SQL Server's distributed queries, `sys.servers`, `sp_serveroption`, `sp_helpserver`, `sp_linkedservers`, `sp_refreshview`, `OPENQUERY` / `EXEC ... AT`, and the Msg 7356 message definition. For some individual cause patterns, the effectiveness of `lazy schema validation` and `SET NOCOUNT ON` depends on the environment, so they are presented as hypotheses to verify rather than confirmed fixes. Provider-specific internal behavior requires verification on the target environment.

よくある質問

What causes Msg 7356?

It is an error indicating that the column metadata a provider returned at compile time for a distributed query disagreed with what it returned at run time. Typical cases are a remote-side view definition that has not kept up with a base-table change, the presence of text-type or computed columns, or a heterogeneous provider that returns different metadata per row.

Does rewriting as OPENQUERY always fix it?

It helps in many cases, but not always. A pass-through has the remote side execute the query and return only the result, reducing metadata round-tripping. However, depending on the heterogeneous provider's implementation, the same kind of error can still occur even through a pass-through.

Can this be run in production?

Checking `sys.servers`, rewriting as `OPENQUERY`, and explicit casting are all read-only and can be run in production. `sp_refreshview` causes a recompile of anything referencing the view, and `sp_serveroption` and `sp_MSset_oledb_prop` have a broad scope of impact, so these assume verification in a test environment first.

What permissions are required?

Checking the configuration requires VIEW ANY DEFINITION or sysadmin. Changing a linked server option requires ALTER ANY LINKED SERVER or sysadmin; changing a provider option requires sysadmin. `sp_refreshview` requires ALTER permission on the target view, on the remote side.

Does this work on AWS RDS?

Amazon RDS for SQL Server has restrictions on using linked servers. Whether you can create one, which providers are supported, and which stored procedures you can run all depend on the service specification, so check the target environment.

How should I interpret the results?

First reproduce it with a four-part name, and if you confirm it succeeds via `OPENQUERY`, you can conclude the cause lies in the local-side metadata-fetch step. From there, exclude columns one at a time to pinpoint the problem column, and cross-reference it against the remote side's definition change history.

この文書がカバーする質問

  • Getting a metadata error on a query through a linked server
  • I want to know why a four-part name fails but OPENQUERY succeeds
  • I want to check a linked server's provider settings

リスク表示の意味

  • 参照のみデータと設定を変更しません。
  • 影響は限定的ですが、権限と負荷の確認が必要です。
  • 性能・ロック・コストに影響する可能性があります。
  • 障害・データ損失・復旧作業が発生する可能性があります。
  • 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

An error through a linked server is a difficult kind of failure to isolate — whether the cause is local, remote, or in the provider — and it often reproduces inconsistently on top of that. At GIIP, for integrations spanning multiple systems, we keep a timeline of which object on which server changed and when, so it can be cross-referenced against when an error started. Changes that affect the whole instance, like a provider option, are excluded from automation — we handle isolation and scoping the impact instead.

執筆・技術検証

GIIP プロダクション運用チーム

大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。

関連するナレッジ

関連サービス

Request help isolating a linked server failure

同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。

Request help isolating a linked server failure

ナレッジベース一覧へ