Keep getting socket exceptions when DbMonitor is not running

Keep getting socket exceptions when DbMonitor is not running

Postby TonyV » Thu 25 Aug 2011 18:15

I'm developing an application that uses dotConnect for PostgreSql and the Linq To Entities Framework 4. I built the entity model using Entity Developer.

When I first started on this application, the program would run fine, even if DbMonitor wasn't running. However, about 2 weeks ago, the program started dying if DbMonitor wasn't started. I was trying to fix an issue with the program not running under XP (I have another thread about that issue, and it's still not resolved, by the way).

Since then, I don't know what I did, but now the program generates the following socket exception whenever I start it & DbMonitor is not running:

No connection could be made because the target machine actively refused it 127.0.0.1:1000

I need to fix this as DbMonitor will not be installed on client machines when the program goes to production.

How do I fix the program so this error no longer occurs?

Thanks

Tony
TonyV
 
Posts: 74
Joined: Wed 25 May 2011 15:03

Postby StanislavK » Fri 26 Aug 2011 15:50

The problem is that a PgSqlMonitor object tries to connect to the dbMonitor application, which is not available.

To resolve the issue, you can perform one of the following:
1) Disable the PgSqlMonitor instance. If you use the monitoring functionality for the testing purposes only, you can disable PgSqlMonitor in the release version of your product.
2) If you do work with PgSqlMonitor inside your application, you can set its UseApp property to false, so that it does not send message to dbMonitor.

Please tell us if this helps.
StanislavK
Devart Team
 
Posts: 1710
Joined: Thu 03 Dec 2009 10:48

So this is normal?

Postby TonyV » Fri 26 Aug 2011 15:59

So what you're saying is the behavior I'm seeing now is normal and the behavior I saw in the past (where the program would run without complaining if dbMonitor wasn't running) isn't normal?

OK, I'll buy that. I suppose I can put the call into a try-catch block & just ignore the exception. And I can put the call to instantiate the object into a #if DEBUG....#endif block so it won't get called in release.

Does that sound OK?

Tony
TonyV
 
Posts: 74
Joined: Wed 25 May 2011 15:03

Postby StanislavK » Fri 26 Aug 2011 17:13

These exceptions should be caught inside the PgSqlMonitor class. If you see them under debug, this may be because you've changed the Visual Studio debug settings to see thrown CLR exceptions (the Debug -> Exceptions item of the Visual Studio main menu). Please tell us if this is not the case.

As for the '#if DEBUG' block, this seems to be a proper solution.
StanislavK
Devart Team
 
Posts: 1710
Joined: Thu 03 Dec 2009 10:48

That's it

Postby TonyV » Fri 26 Aug 2011 19:22

I did change the Debug settings to break when CLR exceptions are thrown! I completely forgot about it!

I'll turn that setting off. That will fix it!

Thanks again!

Tony
TonyV
 
Posts: 74
Joined: Wed 25 May 2011 15:03


Return to dotConnect for PostgreSQL