> Urgent !
>
[quoted text clipped - 24 lines]
>
> DK
You likely got here by using the web interface which merely lists the group
as "Databases", but this is a classic VB (VB6 and lower) newsgroup. Your
post will likely fall on many deaf ears as your first line includes "VC++".
You probably should seek out a VC++ newsgroup. Or better
"microsoft.public.sqlserver.dts".
You failed to mention the database/s you are using. One can assume SQL
Server, but then you mentioned "Jet OLE DB", so I guess it is really
MSAccess??? (But that doesn't really matter. <g>)
Bottom line - DTS often leaks. How bad and where seems to be linked to
particular providers, cursors, and creating and destroying connections. The
'cure' is no different from any other memory leak - try to isolate the exact
location (item) that is leaking and then reworking the architecture to
specifically clean it up. The fix may range from simply keeping one
connection for the life of the app, to moving DTS operations off into some
other process which can be periodically explicitly destroyed.
Using VC++ you have debugging and tracing opportunities available to you
that VB doesn't have out-of-the-box. That is why I suggest a VC++ group may
be more helpful.
hth
-ralph
DK - 30 Oct 2006 09:45 GMT
Thanks Ralph for your suggestion. i have posted it to vc++ newsgroup.
but we use lot of VB Apps in our company . In all of these i have seen
these leaks.
I have asked many developers here but they all have no idea and just
living with it.
I am yet to find a person who has said that he has not seen his DTS
package leak memory.
Then i thought may be there is some other trick or some registry
setting that has to be set and etc.
Till now no help from anywhere.
Regards
DK
> > Urgent !
> >
[quoted text clipped - 49 lines]
> hth
> -ralph
Ralph - 30 Oct 2006 13:54 GMT
> Thanks Ralph for your suggestion. i have posted it to vc++ newsgroup.
>
[quoted text clipped - 9 lines]
>
> Till now no help from anywhere.
<snipped>
I wouldn't lose heart. There is always a solution of fix. Most DTS memory
leaks are of a minor nature since the usual role for a DTS package is to go
do something and then go away. So that is the first key. Get in, get out, go
away. <g>
Second, the DTS designer makes everything so simple and makes it so easy to
cobble something together, we tend to forget that we might not be doing it
in the most efficient manner. Sometimes we use DTS when a simple BCP may
actually be a better option. Many designs as they get more complicated and
chewed on can usually do with a bit of reworking after awhile. A lot of junk
can be lying around.
Several years ago I got the opportunity to work with a SQLServer guru and
DTS wizard (the human kind not the utility). He made me embarressed that I
had included DTS on my resume. <g>
Just take it one critical app at a time. Isolate where, and then apply
common sense. <g>
-ralph