Issues with TELNET and SQLPLUS

Issues with TELNET and SQLPLUS

3
NewbieNewbie
3

    May 04, 2009#1

    I tested this on UE v14.xx and v15.xx

    I login to my Linux based Oracle server via telnet and startup SQLPLUS. While trying to execute anything then trying to cancel the execution the telnet window locks up and UE takes possession of the clipboard. The only way to get my TELNET back is to disconnect then reconnect. To get my clipboard back, I have to shut down UE totally, which sometimes requires me to kill the process via task manager.

    Steps to reproduce
    - select count(*) from all_tables (or some big table that takes a little time)
    - hit CTRL+C to cancel the command (this is a SQLPLUS command, not Linux)
    - TELNET Console locks
    - I can CTRL+C and CTRL+V in the UE Editor with no problem
    If I try to paste (via edit menus or CTRL+V) in any other Windows program I get error message 'Unable to open clipboard'
    Checking Oracle enterprise manager, the command did stop like it was supposed to but the TELNET window never refreshes

    In other TELNET programs when I do this, SQLPLUS comes back with 'User Canceled' message, and gives the SQL prompt back.

    I already have a ticket into support for this, but figured I'd ask anyone else if they have run into this.

    I'll keep this post updated with any fixes they find.
    11
    Basic UserBasic User
    11

      May 14, 2009#2

      The Ctrl-0 through Ctrl-9 keys switch between the UE clipboards (with 0 being the generic Windows clipboard). Once the clipboard locks up try hitting Ctrl-1 or some other number and then Ctrl-0 to switch back to the normal clipboard. Maybe that will do it.
      Two rules of development:
      1) Computers work for people. People do not work for computers.
      2) Maintainability is all that matters.
      3
      NewbieNewbie
      3

        May 21, 2009#3

        Thanks for the idea, Richard. I tried it with no luck. It seems that anytime I do a CTRL+C in telnet, even at the LINUX prompt UE locks up. Even though CTRL+C isn't supposed to do anything in LINUX, it apparently locks up UE pretty badly; and occasionally locks up the clipboard (not always, odd).

        I'll keep this updated if I find out anything.
        11
        Basic UserBasic User
        11

          May 21, 2009#4

          Let's mess around with this a little more. One of my past jobs was being an Oracle DBA. Oracle SQL interactions, especially select statements and so forth, are made at a very low level (sometimes in kernel mode). When you issue a select statement that takes a while to come back your application (terminal, UEStudio, etc.) is locked up in a high-interrupt state and cannot be interrupted except by killing the process or some other scenario with a higher interrupt. In that case any resources your application (UEStudio) has locked will remain locked until your process releases them or the process is killed. You are doing a Ctrl-C to interrupt your Oracle session in the UES Console, but Windows may also be capturing that keystroke and trying to copy something to the clipboard. Now...since UES is probably using threads to do stuff it can still use the clipboard because it "owns" it at the time. However, when you move from UES to another application it cannot use the clipboard because UES still has it locked and has not released it.

          When not in the middle of a SQL statement, are you able to Ctrl-C in the UES Console and still switch to another application and use the clipboard? If so, then the combination of the UES Console being in the middle of a high-interrupt operation may lock the clipboard for everyone but UES itself. If that is the case, then there may not be much that can be done because of the nature of Oracle interfacing.

          Are you able to use another Telnet program terminal, issue the same long select statement, and then Ctrl-C out of the middle of the long SQL statement? That is, if you reproduce the same exact situation in another Telnet terminal program, is it able to cancel and come back? I know that you said that but I just want to confirm that another Telnet program can actually cancel out of the middle of the long SQL select statement. If so, then there may be some difference in the guts of how UES Telnet console and other programs interface with the server. It has been my experience, however, that this kind of scenario happens a lot when interfacing with Oracle and trying to cancel out of the middle of a long statement.

          Thanks!
          Two rules of development:
          1) Computers work for people. People do not work for computers.
          2) Maintainability is all that matters.
          3
          NewbieNewbie
          3

            May 27, 2009#5

            I realized I didn't mention my other tests in this post (I did in the bug report to support).. I did try this exact same test with DOS TELNET and CRT and it worked as expected; the User Abort message came back and the clipboard was never locked up. I realize that long queries can take some time to 'rollback', but these aren't such queries.. it is just a simple select count(*) from all_tables.

            I was able to replicate this actually out of SQLPLUS, just in LINUX if you CTRL+C; UE (not UES, BTW) will lock up and/or just lock the clipboard and not release it.

            Another thing I did that support suggested was to rename my current %APPDATA%/UltraEdit to .bak then try it with a 'vanilla' UE. No joy, still messes up.

            I'm not so sure this has anything to do with SQLPLUS anymore since I can replicate it at just the LINUX prompt.

            Either way, I am almost leaning towards installing PuTTY again just so I don't lockup my favorite text editor anytime I accidentally do a CTRL+C. Thanks for you tenacity in trying to get this solved with me, I have been using UE since last century and it'll always have a special place on my computer =)