Declare @fs_e int, @C_Tables CURSOR, @Table varchar(50)
SET @C_Tables = CURSOR FOR
select name from sysobjects where OBJECTPROPERTY(id, N'IsUserTable') = 1 AND name like 'TR_%'
OPEN @C_Tables
FETCH @C_Tables INTO @Table
SELECT @fs_e = sdec.fetch_Status FROM sys.dm_exec_cursors(0) as sdec where sdec.name = '@C_Tables'
WHILE ( @fs_e <> -1)
BEGIN
exec('Select * from '+ @Table)
FETCH @C_Tables INTO @Table
SELECT @fs_e = sdec.fetch_Status FROM sys.dm_exec_cursors(0) as sdec where sdec.name = '@C_Tables'
END
(Обновленный для полноты)
Вы можете получить доступ к переменным сеанса от любой страницы или управления с помощью Session["loginId"]
и от любого класса (например, из библиотеки классов), с помощью System.Web.HttpContext.Current.Session["loginId"].
, Но продолжаете читать для моего исходного ответа...
<час>я всегда использую класс обертки вокруг сессии ASP.NET для упрощения доступа к переменным сеанса:
public class MySession
{
// private constructor
private MySession()
{
Property1 = "default value";
}
// Gets the current session.
public static MySession Current
{
get
{
MySession session =
(MySession)HttpContext.Current.Session["__MySession__"];
if (session == null)
{
session = new MySession();
HttpContext.Current.Session["__MySession__"] = session;
}
return session;
}
}
// **** add your session properties here, e.g like this:
public string Property1 { get; set; }
public DateTime MyDate { get; set; }
public int LoginId { get; set; }
}
Этот класс хранит один экземпляр себя на сессии ASP.NET и позволяет Вам получать доступ к своим свойствам сессии безопасным с точки зрения типов способом от любого класса, например, как это:
int loginId = MySession.Current.LoginId;
string property1 = MySession.Current.Property1;
MySession.Current.Property1 = newValue;
DateTime myDate = MySession.Current.MyDate;
MySession.Current.MyDate = DateTime.Now;
Этот подход имеет несколько преимуществ:
Получите доступ к Сессии через HttpContext:-
HttpContext.Current.Session["loginId"]
потоков Ответы представили, прежде чем мои предоставляют способные решения проблемы, однако, я чувствую, что важно понять, почему эта ошибка заканчивается:
Session
свойство Page
возвращает экземпляр типа HttpSessionState
относительно того конкретного запроса. Page.Session
на самом деле эквивалентно вызову Page.Context.Session
.
MSDN объясняет, как это возможно:
Поскольку страницы ASP.NET содержат ссылку по умолчанию на Систему. Веб-пространство имен (который содержит
HttpContext
класс), можно сослаться на членовHttpContext
на .aspx странице без полностью определенной ссылки класса кHttpContext
.
Однако, Когда Вы пытаетесь получить доступ к этому свойству в классе в App_Code, свойство не будет доступно Вам, если Ваш класс не произойдет из Класса Страницы.
Мое решение этого часто встреченного сценария состоит в том, что я никогда не передаю объекты страницы классам. Я извлек бы требуемые объекты из страницы Session и передал бы их Классу в форме набора значения имени / Массив / Список, в зависимости от случая.
Проблема предлагаемого решения состоит в том, что оно может нарушить некоторые функции производительности, встроенные в SessionState, если вы используете внепроцессное хранилище сеансов. (либо «Режим сервера состояний», либо «Режим SQL Server»). В режимах oop данные сеанса необходимо сериализовать в конце запроса страницы и десериализовать в начале запроса страницы, что может быть дорогостоящим. Для повышения производительности SessionState пытается десериализовать только то, что необходимо, десериализовать переменную только при первом обращении к ней, и только повторно сериализует и заменяет переменную, которая была изменена. Если у вас есть много переменных сеанса и вы поместите их все в один класс, по сути, все в вашем сеансе будет десериализовано при каждом запросе страницы, который использует сеанс, и все должно быть снова сериализовано, даже если изменилось только 1 свойство, потому что класс изменился. Просто подумайте, если вы используете много сеансов и режим oop.