Sessions

Teradata Studio
Enthusiast

Sessions

When I switch to a new tab in Teradata Studio 15.10 against the same connection I lose any volatile tables when I return to the original tab.  Is Teradata Studio closing the session with Teradata when I switch to a new tab and run a query (even if against the same connection)?

Example:

Tab1 (create volatile table and run queries against volatile table) -> Tab2 (same database connection)(run query against other tables for research) -> Tab1 (queries against originally created volatile tables are unsuccessful because the volatile tables are gone).

Is there a way to prevent this?

Tags (2)
3 REPLIES
Teradata Employee

Re: Sessions

Adam, Studio creates a connection pool for each connection profile. To allow for concurrent queries running, each SQL Editor gets its own connection from the pool. The connection is not closed until you close the SQL Editor.  For your volatile table, you will need to run your queries in the same SQL Editor.

Enthusiast

Re: Sessions

I am running the queries in the same SQL Editor, but the volatile tables disappear if I switch to a different editor and run a totally unrelated query.  When I come back to the original editor and resume work with the volatile tables they are gone as if the session was closed.

Teradata Employee

Re: Sessions

I have tried on Studio 15.10 Win32bits on Window7 with Teradata15.10 database. For first editor tab , I execute this:

CREATE VOLATILE TABLE V_TEMP

(

Empid integer,

Salary decimal(10,2),

Deptno integer

)

ON COMMIT PRESERVE ROWS;

insert into V_TEMP values (1,123.67, 900);

insert into V_TEMP values (2,123.67, 300);

insert into V_TEMP values (3,123.67, 400);

select * from V_TEMP;

-- so I can see 3 rows in the result set viewer.

For second editor tab , I execute this:

select * from testDB.employee;

-- I can see the result from testDB.employee table which comes from the same database as first editor. Then I switch back to first editor and only execute :

select * from V_TEMP;

-- it shows 3 rows in the result set viewer .

As fgrimmer says from above, each SQL editor gets its own connection from the pool . I check DBC.Sessioninfo table which can show the connection is created when executing the first query in a new editor and then the editor holds on the connection. It is working as expected .