I got the same problem, and solved it doing what people said: choosing "Prompt for Debugger Host for Database Debugging". But I thought (prior reading this option carefully) I should set the IP address of my database server. NO ! You should set the IP address of machine running SQL Developer.... I know it's a newbie doubt. It seemed to work correctly (no errors), but I didn't know how to use it yet (couldn't get it to break at specified breakpoints...)
Para os que falam portugês:
Eu tive o mesmo problema, e resolvi fazendo o que os outros disseram: escolhendo "Prompt for Debugger Host for Database Debugging". Mas eu pensei (antes de ler a opção com cuidado) que deveria informar o endereço IP do meu servidor de banco de dados. NÃO ! Você deve informar o endereço IP da máquina que está executando o SQL Developer... Eu sei que é uma dúvida de iniciantes. Pareceu funcionar corretamente (sem erros), mas eu não sei como utilizá-lo ainda (não consegui fazê-lo parar no breakspoints especificados...)
Set your PC's name or IP Address() into popout window of Debugger Host. I am sure it should work.
Because you already connect your database(Solaris), when you debug, your database(Solaris) want to find a port in your PC to debug. In that way, your database(Solaris) use CALL DBMS_DEBUG_JDWP.CONNECT_TCP to connect with your PC to start debug.
Perhaps a tad off topic... Could someone tell me... is there a "debugger connection" (or mechanism of communication) which is a different thing than a "database connection"?
I'm getting the same error that folks are talking about in this thread. I've had sqlDeveloper configured properly for debugging, until I migrated to a new machine. My memory says that I had to specify a port. That is, at the Prompt for Debugger Host dialog, I would enter something that was not the server and port that was used to access the database functions. My memory indicates that the server may well have been the same as the database server (like... it would have to be, no), but the port was different and a specific port.
I've asked my colleagues about the debugger port, the address and port the debugger on the database server (which is not my machine) and they say... uh? Talk to the dba's. I talk to the dba's, they say... there's only one port, if you can connect, you can debug. Well, I can and I can't.
So... on the database server, is there a listener on a port for database access and another listener on another port for debugging purposes? And if so, is it a specific port in the server's configuration, and how would I discover it, since the dba's don't know it?
Thanks in advance.
The port is pretty random; as said in this thread, you can delimit the range on the preferences, but that shouldn't be necessary.
As you can derive from previous posts, the database needs to be able to connect to your machine, not the other way around (if you're trying to debug, it's clear you're already connected to the DB).
That's the way the newer Java debugger works. For databases pre-9.2, which don't support it, you can still use the older Probe debugger (through the preferences). Prompt for Debugger Host should only be necessary when sqldev doesn't fill out your IP automatically.
Solutions and things to check are right here in the thread...
Thanks MRM, I didn't understand that the connection in question was the return trip... that's probably what I was missing. It would default to my IP address, like what would be returned from ipconfig. I'd also tried local host 127.0.0.1, without success. I'd looked over most of this thread without success.
Though we're running 9.2 database, I figured I'd try Probe (Tools/Preferences/PL/SQL Debugger, check Use Probe Debugger). Bang, I'm in :-)
Now... as I step through, the line indicated by the cursor doesn't seem to be the line being executed... it stops on some blank lines and skips some executable statements... but that's another problem ;-)
Thanks again, MRM
Now... as I step through, the line indicated by the
cursor doesn't seem to be the line being executed...
it stops on some blank lines and skips some
executable statements... but that's another problem
The line numbers are usually one off because no allowance is made for the 'create or replace ' at the top of the editor.
The best thing is to experiment to confirm the offset and put all your breakpoints one line down (or up, I can never remember which and I haven't done any Debugging for a while)