Ability to change the query used to get session details in the Session Browser

Toad for Oracle - Beta
1

Hi,

We’ve just migrated to an 11g database, and all of a sudden I’m seeing an “ORA-29275: partial multibyte character” error when I try to view the session browser - it’s due to some bug or other that’s causing the OSUSER to be passed in with a funny/truncated character on the end.

By playing around with the query in the editor, I’ve worked out that I can use the convert function to convert it the OSUSER a single-byte character set and Toad no longer throws the error. I accept that this is not a Toad problem, it’s whatever is passing in the dodgy data. However, I’ve come to rely heavily on the session browser, so having to go back to manual select statements is a major step backwards!

I’ve tried removing that column from the list of visible columns, but that didn’t help. I can also see that I have the ability to create filters on the data, but it does that by doing “select * from v$session where (…)”, and I can’t see a way to amend the columns being selected.

Is it possible to change the columns being selected by the main query in the session browser (similar to how you can amend the query in the schema browser data tab)? If not, is it possible to get that added for the next beta? If it is available, how do I go about doing it?

Thanks,
Dawn

2

Sorry, there is no way to get Toad to not select the column. I could possibly put a change in for beta to not select a column unless it is visible. I will
take a look at that later soon.

From: Boneist [mailto:bounce-Boneist@toadworld.com]

Sent: Monday, July 01, 2013 8:00 AM

To: toadoraclebeta@toadworld.com

Subject: [Toad for Oracle - Beta Discussion Forum] Ability to change the query used to get session details in the Session Browser

Ability to change the query used
to get session details in the Session Browser

Thread created by Boneist

Hi,

We’ve just migrated to an 11g database, and all of a sudden I’m seeing an “ORA-29275: partial multibyte character” error when I try to view the session browser - it’s due to some bug or other
that’s causing the OSUSER to be passed in with a funny/truncated character on the end.

By playing around with the query in the editor, I’ve worked out that I can use the convert function to convert it the OSUSER a single-byte character set and Toad no longer throws the error.
I accept that this is not a Toad problem, it’s whatever is passing in the dodgy data. However, I’ve come to rely heavily on the session browser, so having to go back to manual select statements is a major step backwards!

I’ve tried removing that column from the list of visible columns, but that didn’t help. I can also see that I have the ability to create filters on the data, but it does that by doing "select

  • from v$session where (…)", and I can’t see a way to amend the columns being selected.

Is it possible to change the columns being selected by the main query in the session browser (similar to how you can amend the query in the schema browser data tab)? If not, is it possible to
get that added for the next beta? If it is available, how do I go about doing it?

Thanks,

Dawn

To reply, please reply-all to this email.

Stop receiving emails on this subject.

Or
Unsubscribe from Toad for Oracle - Beta notifications altogether.

Toad for Oracle - Beta Discussion Forum

Flag
this post as spam/abuse.

3

That’s a shame *{:frowning: It’s frustrating to see the query in the filter section, and know that you can only change the where clause. Ah well!

4

Hello,

Has this been fixed at all? I am getting the same problem in version 12.10.0.30.

thanks,

Scott

5

I’m not sure if “fixed” is the right word here, since the error is coming from one of Oracle’s views.

I did investigate the possibility of only selecting the visible columns, but ran into some problems with it, then got pulled into another problem, and honestly, I forgot to come back to this.

Is it caused by the OSUSER column for you too? (you can check by running he same query in the editor). And can you fix it, as Dawn could, with select to_single_byte(osuser) from v$session?

If so, that would be a lot easier than only selecting visible columns, as we use a lot of the non-visible ones internally.

6

The only issue with that is doing things manually as opposed to searching out sessions using the session browser. I don’t have this issue in sqlplus or SQL Developer. It seems to only happen in Toad.

thanks,

Scott

7

Oh, and sorry, forgot to respond to your question. Yes, it is in the OSUSER column.

Thanks,

Scott

8

Sorry for the misunderstanding.

I’m not asking you to work around it manually by just running a query in the editor. I can’t reproduce this problem, so I am wondering if it is the exact same problem as Dawn’s - OSUSER is the only problem column and it can be fixed with the TO_SINGLE_BYTE function. At that point, it’s a simple fix on my side and I can have it done for the next beta.

SQL*Plus uses the OCI in a different way that Toad, and SQL Developer uses JDBC. So they both get data out of the DB in a different way than Toad, so that is likely why you only see the error in Toad.

Thanks.

9

Gotcha. Yes it is the same problem. The OSUSER is the only column causing the problem.

Thanks,

Scott

10

Hi Scott.

OK, next beta, whenever I query OSUSER in the Session Browser, I’ll query it this way: to_single_byte(osuser) as OSUSER.

That should take care of it.

Depending on your settings, this column can also appear in WHERE clauses, but I don’t think the conversion is needed there. Please double-check it for me with this query:

select to_single_byte(osuser) as OSUSER
from v$session s
where (NVL(s.osuser,‘x’) <> ‘SYSTEM’);

if it’s needed in the where clause, I’ll add it there too.

11

Awesome. Thanks.

There’s no issue with the where clause.

12

Hi John,

We ran into the same problem but now related to the ACTION column in (g)v$session.

Would it be possible to also query it using the TO_SINGLE_BYTE() function?

Much appreciated!

Ron

13

So, I guess someone stuck some values in there that your character set didn’t like? Can you try to reproduce the problem with MODULE also? You probably know this, but a session can use DBMS_APPLICATION_INFO.SET_MODULE to put some values into those columns.