Click here to Skip to main content
15,213,821 members

Comments by jschell (Top 11 by date)

jschell 28-Nov-13 13:02pm View
   
You need to provide more information than that - EXACTLY what didn't "work"?

If you are getting a different error message (one that doesn't mention the DSN) then it is different problem
jschell 23-Nov-13 17:00pm View
   
Then the client would be closing it. But it tells you the server is.

As another suggestion if one side uses SSL and the other doesn't you might see this (although I consider that you would see the exact error less likely to appear for that reason.)
jschell 23-Nov-13 16:58pm View
   
Err...do you know what the difference between debug libraries and release libraries is?
jschell 27-Dec-12 14:46pm View
   
Then you should be able to use the above to explicitly hide them (so set it rather that using 'Use Defaults')
jschell 26-Dec-12 13:43pm View
   
The debugger can't trap something that isn't a problem. Until it reaches the problem area it isn't a problem.

Your other apps work because you are using the library differently and/or the execution path is different.

There are libraries that you can use with C++ that allow you to more easily find pointer problems however manual inspection is still your friend (noting again that the problem is caused by code other than that where the exception occurs.)
jschell 10-Sep-12 14:42pm View
   
Nope - I posted what I meant.

Your second example, overall, seems overly complex. That statement has nothing to do with your use of protected.
jschell 10-Sep-12 14:41pm View
   
You could always ask them to cite a source that demonstrates why it is dangerous.

But I suspect the reviewer didn't know what they are talking about.

The point of a "protected" is to allow access by the child.
The point of inheritence is that the child had better understand the contract of the parent.

As one specific case one can allow for a 'default' value which is set by the parent and the child is specifically supposed to override it if they want.
jschell 28-Oct-11 15:00pm View
   
Following is one profiler. I am certain there are others.

http://www.red-gate.com/products/dotnet-development/

To effectively use a profiler you must be able to run your application in a way that simulates real business use. The profiler will not help with that.

Profiling involves two aspect for one method.
- Time how long a single method takes
- How many time the method was called.
To profile an application you do that for all or many methods. Then look at the results for all and determine maximums.

When a database involved you must also profile the database code. Look to a reference specific to your database on how to do that.

In term of 'timing' a method it involves
1. Get the start time.
2. Run method
3. Get the end time.
4. Subtract 1 from 3.

There are other factors such as that it is seldom a good idea to run a method just once nor it is a good idea to time the first run of the method. However that last is only going to apply if you are trying to do this manually.
jschell 27-Oct-11 14:05pm View
   
If you are already using a pool it is unlikely that you will impact performance by closing idle connections. Most likely result of that would be to reduce performance.

If you want to improve performance then stop GUESSING.

Instead measure the application via either an automated profiling tool or by manually inserting timing measurements throughout the code. Using the measurements (not guessing) you then determine where actual performance bottlenecks lie and then you focus your analysis on those arease.
jschell 25-Oct-11 13:50pm View
   
You haven't specified whether you have your own library or are using an existing one.

You also haven't specified why you think it is necessary to discard idle connections.
jschell 24-Oct-11 13:54pm View
   
A idle connection is one that is not being used.
The idle time is the time based on "current time" - "last time used"