@@servername NULL

I am running SQL 7 Standard on a W2K server, both at the most current
service packs. After applying the lastest security update to Windows
and rebooting the server, SQL has suddenly fogottern its name - SELECT
@.@.SERVERNAME returns NULL. In conjuction with this loss of identity,
various maintenance plan jobs seem to hang and never complete. This is
wreaking all sorts of havoc with my backups since none of them complete
successfully.
Will the sp_dropserver/sp_addserver combination fix the NULL problem?
Is there anything else I need to do?
Thanks,
M. E. HoustonYes...the dropserver, addserver should clean it up.
If you query the system table sysserver, you will probably
find that there isn't a server with the srvid = 0. The 0 is
used for the local server. If there is an entry for the
local server and srvid is not 0, you can remove it with
sp_dropserver. Uisng sp_addserver with 'local' adds the
server with the srvid = 0. If you don't specifiy 'local',
it's not added with the 0 for srvid.
-Sue
On Tue, 30 Sep 2003 11:19:09 -0500, meh
<margit.houston@.no_spam.gsiusa.com> wrote:
>I am running SQL 7 Standard on a W2K server, both at the most current
>service packs. After applying the lastest security update to Windows
>and rebooting the server, SQL has suddenly fogottern its name - SELECT
>@.@.SERVERNAME returns NULL. In conjuction with this loss of identity,
>various maintenance plan jobs seem to hang and never complete. This is
>wreaking all sorts of havoc with my backups since none of them complete
>successfully.
>Will the sp_dropserver/sp_addserver combination fix the NULL problem?
>Is there anything else I need to do?
>Thanks,
>M. E. Houston|||This solved my server name problem, but I'm still having
issues with jobs created by maintenance plans hanging. In
order to make them stop, I have to kill the process. When
I do that, the following message gets written to the log --
[Microsoft SQL-DMO (ODBC SQLState: 01000)] Error 0:
[Microsoft][ODBC SQL Server Driver][Shared Memory]
ConnectionRead (recv()).
[Microsoft][ODBC SQL Server Driver][Shared Memory]General
network error. Check your network documentation.
-- Anyone have any clue as to what this really means?
Thanks,
Margit
>--Original Message--
>Yes...the dropserver, addserver should clean it up.
>If you query the system table sysserver, you will probably
>find that there isn't a server with the srvid = 0. The 0
is
>used for the local server. If there is an entry for the
>local server and srvid is not 0, you can remove it with
>sp_dropserver. Uisng sp_addserver with 'local' adds the
>server with the srvid = 0. If you don't specifiy 'local',
>it's not added with the 0 for srvid.
>-Sue|||Just curious based on the first issue and not sure if it's
the issue or not but did you by any chance rename the server
after the jobs were created? Do you have any problems
changing, modifying jobs?
-Sue
On Thu, 2 Oct 2003 13:22:09 -0700, "M. E. Houston"
<margit.houston@.no_spam.gsiusa.com> wrote:
>This solved my server name problem, but I'm still having
>issues with jobs created by maintenance plans hanging. In
>order to make them stop, I have to kill the process. When
>I do that, the following message gets written to the log --
>[Microsoft SQL-DMO (ODBC SQLState: 01000)] Error 0:
>[Microsoft][ODBC SQL Server Driver][Shared Memory]
>ConnectionRead (recv()).
>[Microsoft][ODBC SQL Server Driver][Shared Memory]General
>network error. Check your network documentation.
>-- Anyone have any clue as to what this really means?
>Thanks,
>Margit
>
>>--Original Message--
>>Yes...the dropserver, addserver should clean it up.
>>If you query the system table sysserver, you will probably
>>find that there isn't a server with the srvid = 0. The 0
>is
>>used for the local server. If there is an entry for the
>>local server and srvid is not 0, you can remove it with
>>sp_dropserver. Uisng sp_addserver with 'local' adds the
>>server with the srvid = 0. If you don't specifiy 'local',
>>it's not added with the 0 for srvid.
>>-Sue|||Sorry for the delay in reply.
I did not have any problems making changes to any of the
jobs/maintenance plans either before or after I renamed the server. I
thought the problem might have been a naming issue so I deleted all the
maintenance plans and all the jobs I had created and started over. The
new jobs under the correct server name still exhibit the same bad
behaviour. There doesn't seem to be any consistency as to where in the
job stream things fall apart, i.e., which database in the backup job it
hangs on. On some occassions, the jobs even complete as expected.
Thanks,
Margit
Sue Hoegemeier wrote:
> Just curious based on the first issue and not sure if it's
> the issue or not but did you by any chance rename the server
> after the jobs were created? Do you have any problems
> changing, modifying jobs?
> -Sue|||Sorry for the delay in reply.
I did not have any problems making changes to any of the
jobs/maintenance plans either before or after I renamed the server. I
thought the problem might have been a naming issue so I deleted all the
maintenance plans and all the jobs I had created and started over. The
new jobs under the correct server name still exhibit the same bad
behaviour. There doesn't seem to be any consistency as to where in the
job stream things fall apart, i.e., which database in the backup job it
hangs on. On some occassions, the jobs even complete as expected.
Thanks,
Margit
Sue Hoegemeier wrote:
> Just curious based on the first issue and not sure if it's
> the issue or not but did you by any chance rename the server
> after the jobs were created? Do you have any problems
> changing, modifying jobs?
> -Sue|||Can't tell you for sure why the jobs randomly hang - I've
seen jobs hang when they attempt to send mail and there are
problems somewhere in the mail configuration. You could run
profiler or a trace to try to track down what specifically
is going on when the jobs hang.
-Sue
On Wed, 08 Oct 2003 08:53:32 -0500, meh
<margit.houston@.no_spam.gsiusa.com> wrote:
>Sorry for the delay in reply.
>I did not have any problems making changes to any of the
>jobs/maintenance plans either before or after I renamed the server. I
>thought the problem might have been a naming issue so I deleted all the
>maintenance plans and all the jobs I had created and started over. The
>new jobs under the correct server name still exhibit the same bad
>behaviour. There doesn't seem to be any consistency as to where in the
>job stream things fall apart, i.e., which database in the backup job it
>hangs on. On some occassions, the jobs even complete as expected.
>Thanks,
>Margit
>Sue Hoegemeier wrote:
>> Just curious based on the first issue and not sure if it's
>> the issue or not but did you by any chance rename the server
>> after the jobs were created? Do you have any problems
>> changing, modifying jobs?
>> -Sue