2016-02-25 1 views
2

j'ai un problème dans ma demande delphi avec TADODataSet la simple question après le passage de delphi XE2 à XE9 et sql2014 -je voir dans profileur que toutes mes requêtes ont commencé avec SET NO_BROWSETABLE cette cause recompiler procédures et fonctions stockées dans le serveur SQL quelqu'un peut me dire comment puis-je désactiver cette option et un exemple de codeNO_BROWSETABLE indésirables SET ON générée par TADODataSet

ADODataSet1.Close; ADODataSet1.CommandText: = 'Sélectionnez * de mytable'; ADODataSet1.Open;

et entraîner profileur: SET NO_BROWSETABLE ON Select * from mytable

+0

Qu'est-ce qui vous fait penser que c'est quelque chose à voir avec Delphi? Afaik, le Sql exact envoyé au serveur est déterminé par les couches Ado/MDac "en dessous" de votre code Delphi. Essayez d'utiliser le profileur pour observer ce qui est généré lorsque vous enregistrez une modification dans les données d'une ligne. Souvent, la couche MDac crée un processus stocké temporaire paramétré pour le faire, sans que votre application ne soit impliquée. – MartynA

+0

chercher dans la réponse à cette question: http: // stackoverflow.com/questions/29430665/étrange-ado-comportement-générant-indésirable-non-browsetable-set-fmtonly-requêtes-dans - différents fournisseurs question –

Répondre

2

Votre question semble impliquer que le SET NO_BROWSETABLE ON a seulement commencé depuis le passage à une version plus récente Delphi. Si c'est ce que vous voulez dire, je ne suis pas sûr que votre observation soit exacte, au moins je ne peux reproduire aucune différence de comportement entre une application compilée avec la version Delphi actuelle, XE10 Seattle et Delphi 7 à partir de 15 ans concernant NO_BROWSETABLE .

J'ai une instance de Sql Server 2014 en cours d'exécution sur cette machine, qui est Windows 10 Pro 64 bits. Si je compile et exécute un projet Delphi Seattle minimal qui fait un select * from sometable simple en utilisant un TAdoConnection et un TAdoQuery, le profileur de Sql Server montre la couche MDac envoyant un SET NO_BROWSETABLE ON, comme vous. Cependant, si je compile et exécute exactement le même projet dans Delphi 7, j'obtiens exactement les mêmes instructions montrées dans le profileur - il n'y a aucune différence si l'application est compilée dans D7 ou Seattle. Il s'agit de l'emplacement du curseur défini sur clUseClient. Le SET NO_BROWSETABLE ON ne se produit pas si j'utilise clUseServer. Il ne se produit pas non plus dans une application DBExpress minimale en utilisant un TSqlConnection et TSqlQuery alors peut-être que cela utilise également un curseur côté serveur.

Voir ici pour plus d'informations sur NO_BROWSETABLE:

https://support.microsoft.com/en-us/kb/885146

J'utilise le Microsoft OLE DB Provider for Sql Server. Bien que cela soit considéré comme obsolète par MS, j'ai toujours eu beaucoup moins de problèmes avec celui-ci qu'avec leur fournisseur pour ODBC ou celui "client natif".

Vous pouvez également jeter un oeil à ce q SO:

Strange ADO behavior generating unwanted NO_BROWSETABLE/set fmtonly queries in VB6

vous mentionner sav "XE9". Voulez-vous dire XE8 ou Delphi Seattle ou quoi?

+0

merci pour votre attention d'abord, puis j'ai changé le locktype à itreadonly et je l'ai vu hide et mon problème est résolu je ne peux pas le tester avec d'autres versions de Delphi mais j'ai ma version d'application plus ancienne compilée avec delphi xe2 et je ne vois pas SET NO_BROWSETABLE dans profiler et ma question principale est pourquoi ma procédure sql et la fonction recompilent quand est voir SET NO_BROWSETABLE –

+0

"ma question principale est pourquoi ma procédure sql et la fonction recompilent" Eh bien, je pense que c'est un q différent de ce que vous demandiez à l'origine et donc si vous voulez une réponse, vous devriez l'afficher comme un nouveau q. Je pense que vous devriez inclure dans votre nouveau q tout ce que vous pensez avoir que c'est que "SET NO_BROWSETABLE ON" provoque la recompilation que vous pensez avoir lieu. Comment savez-vous que la recompilation a lieu? – MartynA

+0

SELECT DEST.TEXT à partir de sys. [Dm_exec_connections] SDEC CROSS APPLY sys. [Dm_exec_sql_text] (SDEC. [Most_recent_sql_handle]) AS DEST OÙ SDEC. [Most_recent_session_id] = 393 i voit souvent une fonction de création et de créer la procédure en question l'histoire de mon serveur SQL et après peu de recherche, je comprends que d'autres personnes ont mon même problème à –