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

Applicability of This Document

Ready-to-Run Commands

-- 対象: 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;

-- 対象: SQL Server 2008 以降
-- 権限: リンクサーバーのログインマッピングとリモート側の参照権限
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能（エラー再現の確認用）
-- この形式ではローカル側がリモートのメタデータを取得してプランを作るため 7356 が起きやすい
SELECT col1, col2
FROM [LEGACY-SQL01].[SampleDB].[dbo].[SampleTable];

-- 対象: 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');

-- 対象: 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;

-- 対象: 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;

-- 対象: 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';

-- 対象: 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;

How to Read the Results

When to Use This

• 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

Possible Causes (Most Likely First)

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.

Diagnostic Steps

1. 1

   Check the linked server's configuration and provider

   Read-only

   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

   Read-only

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

3. 3

   Rewrite as `OPENQUERY` and compare behavior

   Read-only

   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

   Read-only

   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

   Read-only

   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

   Read-only

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

Solutions

Differences by Version and Environment

If This Doesn't Resolve It

• 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.

Basis and Limitations of This Document

FAQ

Questions This Document Covers

• 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

What the Risk Labels Mean

• Read-onlyDoes not change data or settings.
• LowImpact is limited, but permissions and load should be checked.
• MediumMay affect performance, locking, or cost.
• HighMay cause an outage, data loss, or require recovery work.
• Expert Review RequiredRequires a separate review before applying to production.

GIIP's Scope of Support

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.

Related Services

• 障害対応・火消し支援
• データベース性能チューニング