Изменение имени приложения при подключении SQL Server

Можно ли изменить имя приложения, переданное на SQL Server (через строку соединения ADO), когда соединение открыто, не закрывая и не открывая соединение?Изменение имени приложения при подключении SQL Server

В частности, я использую ADO, а не ADO.NET, и поставщик SQLLEEDB.1 OLE DB.

Встраиваем информацию о сеансе в имя приложения, чтобы помочь нам идентифицировать соединение, специфичное для сеанса пользователя. Это в первую очередь помогает при устранении проблем с плохими запросами или проблемами производительности.

В настоящее время мы не используем пул соединений для наших соединений ADO. Я рассматриваю возможность внедрения пула соединений, но хочу обновить имя приложения, когда соединение будет удалено из пула, чтобы у нас была точная информация о сеансе в имени приложения.

источник

2011-12-16 Jon Robertson

Я сомневаюсь, что вы можете изменить любой атрибут строки соединения после того, как соединение было создано (в пуле или нет). Соединения равны assigned пулам на основе значения самой строки подключения, поэтому, если вы можете изменить имя приложения после того, как соединение было выбрано из пула, оно по существу будет принадлежать другому пулу с этого момента, что, вероятно, будет беспорядочным управления пулом соединений.

Кроме того, имя приложения используется как (я думаю, вы уже знаете, что, как вы сказали, вы пытаетесь использовать его для определения производительности и устранения неполадок), для заполнения столбца program_namesys.dm_exec_sessions. Поэтому, если нет способа изменить это значение для существующего соединения, я думаю, что нет способа сделать это и из ADO.NET.

После этого я использую имя приложения для этой же цели. Я просто «жестко кодирую» имя приложения в какую-либо символическую строку (например, «myapp-client»), и этого всегда было достаточно, чтобы определить точное приложение-вызов на кричащем сервере (по крайней мере вместе с столбцом host_process_idsys.dm_exec_sessions).

источник

2011-12-19 14:41:50

Я ценю ваш ответ. К сожалению, я не понимал, что ADO имеет свой собственный пул соединений (я думал, что пришел с ADO.NET). Поэтому я потратил некоторое время на изучение и рассмотрение вариантов. Наша архитектура такова, что, как только пользователь получает ADO-соединение, это соединение остается открытым (на нашем сервере), пока пользователь не выйдет из системы. Изменение архитектуры, позволяющей ADO объединить соединения, не является простым вариантом. Моя мысль заключалась в том, чтобы создать свой собственный пул соединений, который все еще является тем, что я планирую. –

Это означает, что мы добавим возможность включения или выключения пула соединений во время работы сервера. Если нам необходимо устранить проблему и выполнить отслеживание активности базы данных пользователя, мы отключим пул соединений, а новые соединения будут иметь имя пользователя в sysprocesses.program_name. Когда пользователи войдут в систему, их соединение будет настроено на основе того, включен ли пул соединений. Включение/выключение включения не приведет к изменению поведения существующих подключений. –

Я предлагаю использовать SQL CONTEXT_INFO, 128 байт доступного для каждого соединения, которое может быть изменено во время выполнения: http://msdn.microsoft.com/en-us/library/ms189252%28v=sql.105%29.aspx

источник

2012-07-02 11:23:17

Я только сейчас заметил ваш ответ, поэтому извиняюсь за поздний ответ. Очень интересное предложение. Не очень легко получить доступ через SQL Profiler, и это основная цель, которую я пытаюсь выполнить (при устранении неполадок с производительностью). Но это должно быть возможно на основе [этого ответа] (http://stackoverflow.com/questions/1049656/how-do-you-access-the-context-info-variable-in-sql2005-profiler) –

Изменение имени приложения при подключении SQL Server

ответ

Смежные вопросы