I'm sorry for asking this question once more, but the topics I found regarding this issue, don't solve my problem.

I'm running a local Apache webserver with PHP 4.3.4 on a Windows XP machine and just installed PhpED for evaluation purposes because I need a professional PHP editor with soffisticated debug features. I did not read the complete manual from cover to cover yet but at least enough to get the debugger to work. However, from the moment I got the debugger to work, phpMyAdmin (version 2.6.4-pl3) no longer works and fails with the following message:

When I disable the debugger, phpMyAdmin works again as expected.

Any hints or tips? What additional information is required to help me solve this problem?

This message means that you debugger is installed and being invoked, but it is not properly configured and therefore fails. PhpAdmis fails as a result of it, because dbg is a php extension which has the control.
please make sure that you debugger is properly set and project mappings are in place - please take a look at this FAQ:
howto-set-project-mapping-t2135.html

Thanks for the swift reply.

As far as I can see, the project settings for the prject I actually want to debug are o.k. and, as I mentioned in my initial post, I'm able to debug that project. Are you implying that I should also create a PhpED project for phpMyAdmin (with all the correct project properties set) in order to be able to run phpMyAdmin whenever the dbg Apache module is active? And if that's the case, should I always have PhpED active whenever dbg is active?

Just to be on the safe side, I'll give some insight into the project I'm debugging:

I'm running Apache on my local Windows machine, with d:\apache\htdocs as my document root. I don't use virtual domains. The project I'm debugging is in d:\apache\htdocs\caketut (a CakePHP tutorial). My project is setup as follows:

Root directory: d:\apache\htdocs\caketut
Root URL: http://localhost/caketut/users/index (the current starting point of the website)
Remote directory: d:\apache\htdocs\caketut

Any comments?

In this case "failed to connect to the client address 127.0.0.1:7869" means one of the following:
a) dbglistener's port is not 7869
b) dbglistener is not running
c) firewall is not letting the connection through

But doesn't the mere fact that I'm able to debug my PhpED project prove that the dbglistener is in fact running and listening on the correct port and that my firewall is in fact letting the connection through? So if that's the case, what am I missing here and why is phpMyAdmin giving me trouble?

Hi there - I am sorry, I am obviously misunderstanding your question - my bad. Here is what I gathered, please correct me if I am wrong:
- you debugged your project (not phpAdmin), no problem there
- you ran through the debug session and now are trying to open PhpMyAdmin - with no intention of debugging it - correct?
- however, the debug session is cookie based and the cookie is still there - that's why it is trying to talk to dbgListener.
If I got it right, the remedy is simple: either open PhpMyAdmin in a separate browser or pass DBGSESSID=-1 to the URL of PhpMyAdmin

I hope it helps. Thanks!

You gathered perfectly right this time and yes indeed, your suggestion certainly helps. Thanks for the advice.

So it appears that every time I want to run any regular PHP application after having debugged a PhpED application, I have to pass the DBGSESSID=-1 along. Although it's only on the first invokation, it is rather cumbersome. By the way, merely running phpMyAdmin (or any other PHP application for that matter) in a separate browser is not enough. Obviously it has to be another kind of browser all together. So when running the PhpED application in FireFox, one has to run all other applications in IE or Opera or whatever other browser is available. As far as I know, FireFox (still) doesn't facilitate seperate session management for individual browser windows/tabs. I didn't try FireFox 2.x yet though.

So thanks once more. For the time being it's an acceptable workaround but I hope NuSphere comes up with a better solution. Especially since I decided to exchange my trial version for a commercial edition which I purchased yesterday

it is enough.
but if you invoke that separate browser as a New Window it will share cookies (including temporary ones) with it's parent browser and subseqently debugger cookie will be there triggereing the debugger.
Either turn debug session off and it will prevent debugger cookie from triggereing the debugger or leave it as is and get what you get