Discussion :

[StringBuilder]

Bonjour,

J'utilise une application tierce qui se connecte à une base de données SQL Server.

Dans cette base de données, j'ai :
1/ des tables
2/ des vues qui pointent sur les-dites tables
3/ des vues qui pointent vers des éléments distants par l'intermédiaire de serveurs liés

L'application tierce faire des opérations simples, du genre "select * from xxx", où j'indique simplement le nom de l'objet sur lequel faire la requête.

Lorsque je mets le nom d'une table, ou le nom d'une vue qui pointe sur des objets locaux, aucun problème.
Lorsque je mets le nom d'une vue qui fait appel à des objets sur les serveurs liés, j'ai un message d'erreur : "la méthode du curseur n'est pas supportée"

Si je fais un "select * into tmp ffrom vue_serveurs_lies" et ensuite j'utilise la table créée, ça fonctionne parfaitement. Donc pas un souci de données.

Qu'est-ce qui peut en être la cause ?

Le programme (pourtant écrit en C#) appelle SQL Server par l'intermédiaire du drivers ODBC plutôt que par le drivers .NET (cherchez pas).

Comment voir côté SQL Server la requête réellement exécutée, et les éventuelles options ODBC (forward only, etc.) pour déduire les sources possibles de l'erreur ? Car le support du logiciel est d'assez mauvaise fois, et nous dit que si ça marche pas, ça vient de notre serveur lié, sans chercher à nous proposer de solution...

[SQLpro]

Parce que vos curseurs sont implémentés côté application. Les requêtes SQL sont produites localement (côté appli) en croyant avoir affaire à une table.
Modifiez les propriété de votre curseur en l'implémentant côté serveur et tout ira mieux !

A +

[StringBuilder]

Merci pour la réponse.

Je vais tâcher de voir avec le support s'ils sont capables de nous fournir un patch allant dans ce sens

[iberserk]

Comment voir côté SQL Server la requête réellement exécutée, et les éventuelles options ODBC (forward only, etc.) pour déduire les sources possibles de l'erreur ? Car le support du logiciel est d'assez mauvaise fois, et nous dit que si ça marche pas, ça vient de notre serveur lié, sans chercher à nous proposer de solution...

Avec un Sql profiler+ sys.dm_exec_sessions/connections pour vois les options de sessions.
Enfin pour les curseurs voir sys.dm_exec_cursors