email erroe

Hello,
I get this error message and nothing gets emailed to me. Help??
Emailing report to operator
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 18025: [Microsoft][ODBC SQL Server Driver][SQL Server]xp_sendmail: failed with mail error 0x80004005
Thanks:)I get the same errror from every couple of days. Do you run GENTRAN software on the computer you are having the problem with?

[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 18025: [Microsoft][ODBC SQL Server Driver][SQL Server]xp_sendmail: failed with mail error 0x80004005|||Do you receive the error every time ?|||No we did not get the error every time, but almost exactly every 3 days or third time the XP_SENDMAIL function was invoked during auto-notification of backups completeing.

I found the solution earlier today the technet article is at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;320407

There is a hotfix for it to replace the Sqlmap70.dll with this version:
Version File name
----------
8.00.603 Sqlmap70.dll

I called Microsoft support and they emailed me a link to a hotfix file. I used the 1-800-936-4900 number from:
http://support.microsoft.com/default.aspx?scid=fh;en-us;Prodoffer41a

This hotfix has not been fully regression tested so they are only handing it out to customers with this exact problem.

All the is needed is to stop SQL Server backup the old dll, copy the new dll to the same location, and restart SQL Server.

I will know if it is fixed if I do not have any email problems/errors this week.|||jcreed - thanks for posting the solution to your problem with xp_sendmail (which is the same problem that I had a few months ago and fixed with the same methods that you did) - however, there is an intermittent problem and a steady problem with xp_sendmail.

Anu - If your problem is every x days then I would pursue the listing by jcreed; otherwise, let me know.|||xp_sendmail: failed with mail error 0x80004005
I had the same problem a while ago after System Administartor added NT login restriction on the SQL 2000 server. This has been resolved by stop and restart the services of SQLSERVERAGENT and MSSQLSERVER. I do not know if this is the case for you but it worked with me. So try it if this happens again.

EM DTS Designer ODBC source as a file DSN doesnt work!

Hi All there!

I am quite new in MS SQL administration so let me explain how it work
on Your instances of SQL Servers.
We have several DTS packages on our server, all of them managed on
some station which have seriously hardvare problem. So we wolud like
to catch two problems at one time and decided to develop systematic
way of DTS manipulation.
One of several aspects of this operation would be migration from
system ODBC data sources definitions into file ODBC sources ( .dsn
files) in order to make them easier to manage ( backup for example,
and even reusability on other workstations). All .dsn files should be
located on some network resource (\\server\\directory\...) which would
be set as default ODBC directory in ODBC administrator on management
station.
When I begin to do so, then it apears that EM DTS Designer does not
remember the path to the DSN files ( for example on design panel I
chose file dsn and by browse button point at the certain .dsn file,
and then after DTS save the path disapears).

Do You use this facility ( file .dsn) in DTS EM Designer, or maybe MS
has it treated as usless, and nobody wants to use this?

Regards
K"kakaz" <kakazpl@.yahoo.com> wrote in message
news:efd3e15d.0401140621.2b4eb48b@.posting.google.c om...
> Hi All there!
> I am quite new in MS SQL administration so let me explain how it work
> on Your instances of SQL Servers.
> We have several DTS packages on our server, all of them managed on
> some station which have seriously hardvare problem. So we wolud like
> to catch two problems at one time and decided to develop systematic
> way of DTS manipulation.
> One of several aspects of this operation would be migration from
> system ODBC data sources definitions into file ODBC sources ( .dsn
> files) in order to make them easier to manage ( backup for example,
> and even reusability on other workstations). All .dsn files should be
> located on some network resource (\\server\\directory\...) which would
> be set as default ODBC directory in ODBC administrator on management
> station.
> When I begin to do so, then it apears that EM DTS Designer does not
> remember the path to the DSN files ( for example on design panel I
> chose file dsn and by browse button point at the certain .dsn file,
> and then after DTS save the path disapears).
> Do You use this facility ( file .dsn) in DTS EM Designer, or maybe MS
> has it treated as usless, and nobody wants to use this?
> Regards
> K

You may wish to consider adapting your approach slightly, and modifying the
properties of the Connection objects within the packages directly. I
commonly start a package with a dynamic properties task which assigns global
variable values to various connection properties (server names, database
names, file names etc.) Since you can pass global variables to DTSRUN.EXE,
it's straightforward to build a command line with the variable values you
need; if passwords are required, then DTSRUNUI.EXE will encrypt the command
line for you.

Alternatively, you can use Execute SQL tasks within the package to retrieve
the values from a table and assign them to the global variables first. This
is handy because you can then store all connection properties for all
packages on all servers in one central database, then use @.@.SERVERNAME,
DB_NAME() etc. to find the appropriate values for the current execution.

No doubt there are other possible approaches, but this one works well enough
for me.

Simon|||"Simon Hayes" <sql@.hayes.ch> wrote in message news:<400591b3_3@.news.bluewin.ch>...
> You may wish to consider adapting your approach slightly, and modifying the
> properties of the Connection objects within the packages directly.

Hi!
Thanks for your suggestion but this is no option for us, because of
organisational purposes, mainly because I am only administrator of
this bounch of DTSes and our developer not exactly agree with your
idea. I dont want to change his codes...

But do You have similar problem with DTS Designer? Would like to
chceck this for me on Your SQL Server?

I am not sure if it is problem with EM DTS Designer or with our
environment because we have for example some conflicts with ODBC IBM
Client Access for AS400 libreries so operation system with this
combination ( MS SQL Server + IBM Client Access ) is not stable but
rather hacked to be stable ( we have to make replacemement in some of
system libraries, mainly by Visual Studio installation which resolve
conflict).

est Regards
K|||kakazpl@.yahoo.com (kakaz) wrote in message news:<efd3e15d.0401142307.7499a374@.posting.google.com>...
> "Simon Hayes" <sql@.hayes.ch> wrote in message news:<400591b3_3@.news.bluewin.ch>...
> > You may wish to consider adapting your approach slightly, and modifying the
> > properties of the Connection objects within the packages directly.
> Hi!
> Thanks for your suggestion but this is no option for us, because of
> organisational purposes, mainly because I am only administrator of
> this bounch of DTSes and our developer not exactly agree with your
> idea. I dont want to change his codes...
>
> But do You have similar problem with DTS Designer? Would like to
> chceck this for me on Your SQL Server?
> I am not sure if it is problem with EM DTS Designer or with our
> environment because we have for example some conflicts with ODBC IBM
> Client Access for AS400 libreries so operation system with this
> combination ( MS SQL Server + IBM Client Access ) is not stable but
> rather hacked to be stable ( we have to make replacemement in some of
> system libraries, mainly by Visual Studio installation which resolve
> conflict).
> est Regards
> K

I tested quickly, and it does seem that the designer always looks in
the same folder (the local Data Sources folder on my workstation),
whatever I do. Even setting a different default folder in the
workstation Data Sources (ODBC) Control Panel applet doesn't affect
this, so I would guess it's a 'feature' of the designer.

But hopefully this should just be a minor inconvenience when you're
designing. When you have a working package, it's much easier to change
the connections programmatically from a script (inside or outside the
package) than it is to use the designer. The designer may force you to
update transformations which don't need to be updated, for example.
But I don't have much experience of using the Client Access providers
in DTS, so there may be some extra considerations.

Simon

EM connects to server without knowing port

I'm confused. When I create an ODBC connection to a remote SQL server 2000
that uses a nonstandard TCP port, I have to give the port number to ODBC.
Which makes sense.
I just set up an Enterprise Manager "SQL Server Registration" for the same
remote server, and I gave it the IP address of the server computer, and
nowhere did it ask me for the port number. I thought "I won't be able to
connect unless I can tell EM what port to talk on".
But EM is able to connect to the server. Does it try all 65535 ports until
it finds a SQL server?
I'm sure the remote server is listening on the nonstandard port number I
gave; the server log says so.
Query Analyzer connects also. How does this work? What information am I
missing here so I can understand what's going on?
Thanks. I appreciate any help.
David WalkerHi
Wonders of Port 1434.
From BOL:
"When the SQL Server 2000 client Net-Libraries connect to an instance of SQL
Server 2000, only the network name of the computer running the instance and
the instance name are required. When an application requests a connection to
a remote computer, Dbnetlib.dll opens a connection to UDP port 1434 on the
computer network name specified in the connection. All computers running an
instance of SQL Server 2000 listen on this port. When a client Dbnetlib.dll
connects to this port, the server returns a packet listing all the instances
running on the server. For each instance, the packet reports the server
Net-Libraries and network addresses the instance is listening on. After the
Dbnetlib.dll on the application computer receives this packet, it chooses a
Net-Library that is enabled on both the application computer and on the
instance of SQL Server, and makes a connection to the address listed for
that Net-Library in the packet."
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"DWalker" <none@.none.com> wrote in message
news:uelxNLeFFHA.628@.TK2MSFTNGP15.phx.gbl...
> I'm confused. When I create an ODBC connection to a remote SQL server
2000
> that uses a nonstandard TCP port, I have to give the port number to ODBC.
> Which makes sense.
> I just set up an Enterprise Manager "SQL Server Registration" for the same
> remote server, and I gave it the IP address of the server computer, and
> nowhere did it ask me for the port number. I thought "I won't be able to
> connect unless I can tell EM what port to talk on".
> But EM is able to connect to the server. Does it try all 65535 ports
until
> it finds a SQL server?
> I'm sure the remote server is listening on the nonstandard port number I
> gave; the server log says so.
> Query Analyzer connects also. How does this work? What information am I
> missing here so I can understand what's going on?
> Thanks. I appreciate any help.
>
> David Walker|||Ah. Thanks. I see that in Client Network Utility, there's an alias for
the IP address with a comma and the port number.
How is the option "hide SQL server" related? I read that it changes the
UDP port to 2433 or something, but it actually seemed to change the TCP
port that I see in the Server Network Utility from my hand-picked port
to 2433 or something.
This part is kind of confusing. If you can explain the Hide part, it
would be great. I would like the SQL server to not listen on that port
and respond to just anyone who asks!
Thanks for any further enlightenment you can give.
David Walker
"Mike Epprecht \(SQL MVP\)" <mike@.epprecht.net> wrote in
news:#nkcTBgFFHA.2928@.TK2MSFTNGP14.phx.gbl:

> Hi
> Wonders of Port 1434.
> From BOL:
> "When the SQL Server 2000 client Net-Libraries connect to an instance
> of SQL Server 2000, only the network name of the computer running the
> instance and the instance name are required. When an application
> requests a connection to a remote computer, Dbnetlib.dll opens a
> connection to UDP port 1434 on the computer network name specified in
> the connection. All computers running an instance of SQL Server 2000
> listen on this port. When a client Dbnetlib.dll connects to this port,
> the server returns a packet listing all the instances running on the
> server. For each instance, the packet reports the server Net-Libraries
> and network addresses the instance is listening on. After the
> Dbnetlib.dll on the application computer receives this packet, it
> chooses a Net-Library that is enabled on both the application computer
> and on the instance of SQL Server, and makes a connection to the
> address listed for that Net-Library in the packet."
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "DWalker" <none@.none.com> wrote in message
> news:uelxNLeFFHA.628@.TK2MSFTNGP15.phx.gbl...
> 2000
> until
>
>|||Hi
Broadcasts from clients attempting to enumerate those instances of SQL
Server present on the network are disabled when you tick the 'Hide" option.
In effect, it listens, but does not respond.
Security through obfustication does not work. A simple port scan fro ma
machine on a network fill quickly find out what is running on a machine.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"DWalker" <none@.none.com> wrote in message
news:uPgvdWhFFHA.628@.TK2MSFTNGP15.phx.gbl...
> Ah. Thanks. I see that in Client Network Utility, there's an alias for
> the IP address with a comma and the port number.
> How is the option "hide SQL server" related? I read that it changes the
> UDP port to 2433 or something, but it actually seemed to change the TCP
> port that I see in the Server Network Utility from my hand-picked port
> to 2433 or something.
> This part is kind of confusing. If you can explain the Hide part, it
> would be great. I would like the SQL server to not listen on that port
> and respond to just anyone who asks!
> Thanks for any further enlightenment you can give.
> David Walker
>
> "Mike Epprecht \(SQL MVP\)" <mike@.epprecht.net> wrote in
> news:#nkcTBgFFHA.2928@.TK2MSFTNGP14.phx.gbl:
>
>|||Thanks. You said:
"Mike Epprecht \(SQL MVP\)" <mike@.epprecht.net> wrote in
news:ujNrUhhFFHA.3032@.TK2MSFTNGP12.phx.gbl:

> Hi
> Broadcasts from clients attempting to enumerate those instances of SQL
> Server present on the network are disabled when you tick the 'Hide"
> option.
> In effect, it listens, but does not respond.
> Security through obfustication does not work. A simple port scan fro
> ma machine on a network fill quickly find out what is running on a
> machine.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
>
I know that security through obfuscation doesn't work. I wanted the
server to use TCP port 12345 (well, a different port really), and also
not broadcast its presence to clients that are looking for it -- in
effect, I was trying to force the clients to specify the exact port.
Apparently SQL server can't really do this. I found KB article 308091
which helps. I now see that there's a data port that defaults to 1433
but can be changed, and a pre-session handshake port of UDP 1434 which
apparently can't be changed, or can be changed to 2433, or something
equally vague.
And I was confused that I didn't have to (and couldn't see HOW to)
specify the exact port from Enterprise Manager. The dialog box asks for
a server; it doesn't give any clues how to specify an IP address plus a
port. Is there a way to do this?
By the way, you said that BOL says "Dbnetlib.dll opens a connection to
UDP port 1434 on the computer network name specified in the connection.
All computers running an instance of SQL Server 2000 listen on this
port.". What topic is this? I couldn't find it.
Sorry for so many questions... Thanks.
David Walker|||AND, the TCP port number given in the Client Network Utility seems a little
odd now that I think about it. You can specify *A* default port. Suppose
I connect to SQL servers on several machines, each with its SQL server
listening on a specific, different port. There's no way to pre-specify the
TCP data port for a given IP address?
I suppose that's why SQL servers listen on UDP port 1434, so they can reply
with their data port number. Seems like an odd design. The client should
be made to specify the port number if I have changed it on the server.
David|||Hi
You can, use the format:
servername, portnumber
or
ip address, portnumber
All the SQL 2000 Tools support it, as well as MDAC v2.5 and later.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"DWalker" <None> wrote in message
news:Xns9602EAD299831DWalker@.207.46.248.16...
> AND, the TCP port number given in the Client Network Utility seems a
little
> odd now that I think about it. You can specify *A* default port. Suppose
> I connect to SQL servers on several machines, each with its SQL server
> listening on a specific, different port. There's no way to pre-specify
the
> TCP data port for a given IP address?
> I suppose that's why SQL servers listen on UDP port 1434, so they can
reply
> with their data port number. Seems like an odd design. The client should
> be made to specify the port number if I have changed it on the server.
>
> David
>

EM connects to server without knowing port

I'm confused. When I create an ODBC connection to a remote SQL server 2000
that uses a nonstandard TCP port, I have to give the port number to ODBC.
Which makes sense.
I just set up an Enterprise Manager "SQL Server Registration" for the same
remote server, and I gave it the IP address of the server computer, and
nowhere did it ask me for the port number. I thought "I won't be able to
connect unless I can tell EM what port to talk on".
But EM is able to connect to the server. Does it try all 65535 ports until
it finds a SQL server?
I'm sure the remote server is listening on the nonstandard port number I
gave; the server log says so.
Query Analyzer connects also. How does this work? What information am I
missing here so I can understand what's going on?
Thanks. I appreciate any help.
David Walker
Hi
Wonders of Port 1434.
From BOL:
"When the SQL Server 2000 client Net-Libraries connect to an instance of SQL
Server 2000, only the network name of the computer running the instance and
the instance name are required. When an application requests a connection to
a remote computer, Dbnetlib.dll opens a connection to UDP port 1434 on the
computer network name specified in the connection. All computers running an
instance of SQL Server 2000 listen on this port. When a client Dbnetlib.dll
connects to this port, the server returns a packet listing all the instances
running on the server. For each instance, the packet reports the server
Net-Libraries and network addresses the instance is listening on. After the
Dbnetlib.dll on the application computer receives this packet, it chooses a
Net-Library that is enabled on both the application computer and on the
instance of SQL Server, and makes a connection to the address listed for
that Net-Library in the packet."
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"DWalker" <none@.none.com> wrote in message
news:uelxNLeFFHA.628@.TK2MSFTNGP15.phx.gbl...
> I'm confused. When I create an ODBC connection to a remote SQL server
2000
> that uses a nonstandard TCP port, I have to give the port number to ODBC.
> Which makes sense.
> I just set up an Enterprise Manager "SQL Server Registration" for the same
> remote server, and I gave it the IP address of the server computer, and
> nowhere did it ask me for the port number. I thought "I won't be able to
> connect unless I can tell EM what port to talk on".
> But EM is able to connect to the server. Does it try all 65535 ports
until
> it finds a SQL server?
> I'm sure the remote server is listening on the nonstandard port number I
> gave; the server log says so.
> Query Analyzer connects also. How does this work? What information am I
> missing here so I can understand what's going on?
> Thanks. I appreciate any help.
>
> David Walker
|||Ah. Thanks. I see that in Client Network Utility, there's an alias for
the IP address with a comma and the port number.
How is the option "hide SQL server" related? I read that it changes the
UDP port to 2433 or something, but it actually seemed to change the TCP
port that I see in the Server Network Utility from my hand-picked port
to 2433 or something.
This part is kind of confusing. If you can explain the Hide part, it
would be great. I would like the SQL server to not listen on that port
and respond to just anyone who asks!
Thanks for any further enlightenment you can give.
David Walker
"Mike Epprecht \(SQL MVP\)" <mike@.epprecht.net> wrote in
news:#nkcTBgFFHA.2928@.TK2MSFTNGP14.phx.gbl:

> Hi
> Wonders of Port 1434.
> From BOL:
> "When the SQL Server 2000 client Net-Libraries connect to an instance
> of SQL Server 2000, only the network name of the computer running the
> instance and the instance name are required. When an application
> requests a connection to a remote computer, Dbnetlib.dll opens a
> connection to UDP port 1434 on the computer network name specified in
> the connection. All computers running an instance of SQL Server 2000
> listen on this port. When a client Dbnetlib.dll connects to this port,
> the server returns a packet listing all the instances running on the
> server. For each instance, the packet reports the server Net-Libraries
> and network addresses the instance is listening on. After the
> Dbnetlib.dll on the application computer receives this packet, it
> chooses a Net-Library that is enabled on both the application computer
> and on the instance of SQL Server, and makes a connection to the
> address listed for that Net-Library in the packet."
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "DWalker" <none@.none.com> wrote in message
> news:uelxNLeFFHA.628@.TK2MSFTNGP15.phx.gbl...
> 2000
> until
>
>
|||Hi
Broadcasts from clients attempting to enumerate those instances of SQL
Server present on the network are disabled when you tick the 'Hide" option.
In effect, it listens, but does not respond.
Security through obfustication does not work. A simple port scan fro ma
machine on a network fill quickly find out what is running on a machine.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"DWalker" <none@.none.com> wrote in message
news:uPgvdWhFFHA.628@.TK2MSFTNGP15.phx.gbl...
> Ah. Thanks. I see that in Client Network Utility, there's an alias for
> the IP address with a comma and the port number.
> How is the option "hide SQL server" related? I read that it changes the
> UDP port to 2433 or something, but it actually seemed to change the TCP
> port that I see in the Server Network Utility from my hand-picked port
> to 2433 or something.
> This part is kind of confusing. If you can explain the Hide part, it
> would be great. I would like the SQL server to not listen on that port
> and respond to just anyone who asks!
> Thanks for any further enlightenment you can give.
> David Walker
>
> "Mike Epprecht \(SQL MVP\)" <mike@.epprecht.net> wrote in
> news:#nkcTBgFFHA.2928@.TK2MSFTNGP14.phx.gbl:
>
|||Thanks. You said:
"Mike Epprecht \(SQL MVP\)" <mike@.epprecht.net> wrote in
news:ujNrUhhFFHA.3032@.TK2MSFTNGP12.phx.gbl:

> Hi
> Broadcasts from clients attempting to enumerate those instances of SQL
> Server present on the network are disabled when you tick the 'Hide"
> option.
> In effect, it listens, but does not respond.
> Security through obfustication does not work. A simple port scan fro
> ma machine on a network fill quickly find out what is running on a
> machine.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
>
I know that security through obfuscation doesn't work. I wanted the
server to use TCP port 12345 (well, a different port really), and also
not broadcast its presence to clients that are looking for it -- in
effect, I was trying to force the clients to specify the exact port.
Apparently SQL server can't really do this. I found KB article 308091
which helps. I now see that there's a data port that defaults to 1433
but can be changed, and a pre-session handshake port of UDP 1434 which
apparently can't be changed, or can be changed to 2433, or something
equally vague.
And I was confused that I didn't have to (and couldn't see HOW to)
specify the exact port from Enterprise Manager. The dialog box asks for
a server; it doesn't give any clues how to specify an IP address plus a
port. Is there a way to do this?
By the way, you said that BOL says "Dbnetlib.dll opens a connection to
UDP port 1434 on the computer network name specified in the connection.
All computers running an instance of SQL Server 2000 listen on this
port.". What topic is this? I couldn't find it.
Sorry for so many questions... Thanks.
David Walker
|||AND, the TCP port number given in the Client Network Utility seems a little
odd now that I think about it. You can specify *A* default port. Suppose
I connect to SQL servers on several machines, each with its SQL server
listening on a specific, different port. There's no way to pre-specify the
TCP data port for a given IP address?
I suppose that's why SQL servers listen on UDP port 1434, so they can reply
with their data port number. Seems like an odd design. The client should
be made to specify the port number if I have changed it on the server.
David
|||Hi
You can, use the format:
servername, portnumber
or
ip address, portnumber
All the SQL 2000 Tools support it, as well as MDAC v2.5 and later.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"DWalker" <None> wrote in message
news:Xns9602EAD299831DWalker@.207.46.248.16...
> AND, the TCP port number given in the Client Network Utility seems a
little
> odd now that I think about it. You can specify *A* default port. Suppose
> I connect to SQL servers on several machines, each with its SQL server
> listening on a specific, different port. There's no way to pre-specify
the
> TCP data port for a given IP address?
> I suppose that's why SQL servers listen on UDP port 1434, so they can
reply
> with their data port number. Seems like an odd design. The client should
> be made to specify the port number if I have changed it on the server.
>
> David
>