Error 705 while restoring transaction logs

While in the process of restoring a large number of
transaction logs, I recieved the following error
"There not enough room for process 11 to store PROC_HDR
0x5975000 in Pss.
What doesn't it have room for? The system databases have
plenty of room.
The error occurred on the 14th of about 30 transaction
logs being loaded. I am using SQL 6.5, I am unsure of the
service pack level, it migt be 5a (the build number is
6.50.479).
Any help would be greatly appreciatedDaniel,
PSS here stands for "process status structure" and refers to something SQL
Server keeps in memory. In effect, the message is saying SQL Server ran out
of memory in some buffer area. Were you able to finish the restores?
Ron
--
Ron Talmage
SQL Server MVP
"Daniel Inman" <dwinman.ns@.iqe.com> wrote in message
news:00f401c356cb$73274890$a601280a@.phx.gbl...
> While in the process of restoring a large number of
> transaction logs, I recieved the following error
> "There not enough room for process 11 to store PROC_HDR
> 0x5975000 in Pss.
> What doesn't it have room for? The system databases have
> plenty of room.
> The error occurred on the 14th of about 30 transaction
> logs being loaded. I am using SQL 6.5, I am unsure of the
> service pack level, it migt be 5a (the build number is
> 6.50.479).
> Any help would be greatly appreciated
>|||Thank you for your response, but unfortunately, we
couldn't continue restoring logs. The database was
marked suspect as a result of the error, and in 6.5 it
seems that you can't restore a corrupt database without
dropping it first. My client was getting nervous over
the downtime so we gave upon restoring the transaction
logs and went back to the last full backup. I don't know
what would have happened if I had tried the entire
restore process again - just restoring the full backup
took over five hours - the DB is over 5gb.
I am just concerned that I may encounter the same error
the next time I have to restore transaction logs for this
client. For future reference, do you think this was
related to some attribute of the transaction log it faile
on, such as size or contents? Does it matter that I ran
the load database in the same batch as the load
transaction?
Daniel Inman
>--Original Message--
>Daniel,
>PSS here stands for "process status structure" and
refers to something SQL
>Server keeps in memory. In effect, the message is saying
SQL Server ran out
>of memory in some buffer area. Were you able to finish
the restores?
>Ron
>--
>Ron Talmage
>SQL Server MVP
>
>"Daniel Inman" <dwinman.ns@.iqe.com> wrote in message
>news:00f401c356cb$73274890$a601280a@.phx.gbl...
>> While in the process of restoring a large number of
>> transaction logs, I recieved the following error
>> "There not enough room for process 11 to store PROC_HDR
>> 0x5975000 in Pss.
>> What doesn't it have room for? The system databases
have
>> plenty of room.
>> The error occurred on the 14th of about 30 transaction
>> logs being loaded. I am using SQL 6.5, I am unsure of
the
>> service pack level, it migt be 5a (the build number is
>> 6.50.479).
>> Any help would be greatly appreciated
>
>.
>

Error 64 while backup TL onto NAS

Dear All,
I have a problem that I cannot seem to find much info on. I am backing up
SQL 2000 Transaction logs onto a network share (NAS). This share is
connected to the SQL server by a gigabit switch. When backing up the
transactions logs overnight - I find that the SQL server reports errors
"Operating System error 64 (The specified network name is no longer
available). Error 15457 Severity:0, State:1 on large logs (over 1Gb) - it
seems to backup smaller logs ok.
The SQL server is up to date with the SP3a as are the servers (Windows 2K -
SP4). The Transaction logs are 1Gb or over - some are 4Gb+ (this is a
back-end DB for a large web site).
Can someone point me in the right direction please.
PS. I have applied the MS KB813130 hot fix - this has had no effect.
Thanks
Andrew.Andrew,
This suggests that you are overrunning the ability of the target machine to
keep up with your request. We had problems with this at one time (and are
sneaking back up on it again.) Here are a couple posts from Google that
might help you.
http://tinyurl.com/wtm3
http://tinyurl.com/wtmb Jasper Smith, MVP wrote this response about RAID5
drives.
Russell Fields
"andrew" <andrew_loftus@.hotmail.com> wrote in message
news:%23G2XEPRtDHA.1224@.TK2MSFTNGP09.phx.gbl...
> Dear All,
> I have a problem that I cannot seem to find much info on. I am backing up
> SQL 2000 Transaction logs onto a network share (NAS). This share is
> connected to the SQL server by a gigabit switch. When backing up the
> transactions logs overnight - I find that the SQL server reports errors
> "Operating System error 64 (The specified network name is no longer
> available). Error 15457 Severity:0, State:1 on large logs (over 1Gb) - it
> seems to backup smaller logs ok.
> The SQL server is up to date with the SP3a as are the servers (Windows
2K -
> SP4). The Transaction logs are 1Gb or over - some are 4Gb+ (this is a
> back-end DB for a large web site).
> Can someone point me in the right direction please.
> PS. I have applied the MS KB813130 hot fix - this has had no effect.
> Thanks
> Andrew.
>|||Hi Andrew,
My name is Michael and I would like to thank you for using Microsoft
newsgroup.
Before you troubleshoot the SQL Server, I would like you to check if the
network configration is correct and if the status of the network is normal
on your side when the error occurred. I would like to try excluding the
network reason for this problem so that we can narrow down this issue on
SQL Server.
Based on my research, there is a known issue that if the database size is
big, such as 20 GB, and using a network share name for the backup file, it
can fail with Operating System error 64 (The specified network name is no
longer available.) or 121 (The semaphore timeout period has expired.) when
multiple files are used. The workaround is to use the file path instead of
the network share name for the backup file(s).
Does it solve your problem? If not, I would like you to provide more
information so that I can perform further research.
1. How is the issue going on your side now? Did the problem occur before?
Does the problem occur again? Does it occur randomly?
2. Please provide the Sqldiag.txt (by default located in \Mssql\Log) using
Sqldiag utility (Sqldiag.exe by default located in C:\Program
Files\Microsoft SQL Server\MSSQL\Binn). If you are unable to find the
Sqldiag.exe, please search and run the utility. Then please search the
Sqldiag.txt file and provide it to me at v-yshao@.microsoft.com
Also, such issues tend to be complex and take up extensive research time.
I'd like to set your expectations that it may take a while for us to help
you narrow down the problem and we may eventually redirect you to PSS to
continue working with a dedicated Support Professional. If this is
critical, I'd recommend contacting PSS and opening a Support incident to
troubleshoot this further. If you need any help in this regard, please let
me know.
I am standing by for your response.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||Michael,
Thank you for the reply.
I seem to be able to backup the Tlogs to the local disk and only have the
problem when trying to backup to the N/W share. I was backing up to local
disk and have recently purchased this NAS to backup onto (over £3,000) - the
errors occured when using this NAS.
My Tlog files are no bigger than 6Gb at the moment and it is only the bigger
ones (over 1Gb) that seem to give the error. I assume MS software can handle
this kind of transfer with proper "handshaking" to ensure the share does not
get swamped with data it cannot handle. The NAS is a DELL 725n with "Windows
2000" powered software. The disks are configured in a RAID5 array. This
problem does occur on a regular daily basis.
Thanks
Andrew.
I have emailed you the SQLDIAG.TXT seperatly to your email address.
"Michael Shao [MSFT]" <v-yshao@.online.microsoft.com> wrote in message
news:EX4O1RYtDHA.2072@.cpmsftngxa06.phx.gbl...
> Hi Andrew,
> My name is Michael and I would like to thank you for using Microsoft
> newsgroup.
> Before you troubleshoot the SQL Server, I would like you to check if the
> network configration is correct and if the status of the network is normal
> on your side when the error occurred. I would like to try excluding the
> network reason for this problem so that we can narrow down this issue on
> SQL Server.
> Based on my research, there is a known issue that if the database size is
> big, such as 20 GB, and using a network share name for the backup file, it
> can fail with Operating System error 64 (The specified network name is no
> longer available.) or 121 (The semaphore timeout period has expired.) when
> multiple files are used. The workaround is to use the file path instead
of
> the network share name for the backup file(s).
> Does it solve your problem? If not, I would like you to provide more
> information so that I can perform further research.
> 1. How is the issue going on your side now? Did the problem occur before?
> Does the problem occur again? Does it occur randomly?
> 2. Please provide the Sqldiag.txt (by default located in \Mssql\Log) using
> Sqldiag utility (Sqldiag.exe by default located in C:\Program
> Files\Microsoft SQL Server\MSSQL\Binn). If you are unable to find the
> Sqldiag.exe, please search and run the utility. Then please search the
> Sqldiag.txt file and provide it to me at v-yshao@.microsoft.com
> Also, such issues tend to be complex and take up extensive research time.
> I'd like to set your expectations that it may take a while for us to help
> you narrow down the problem and we may eventually redirect you to PSS to
> continue working with a dedicated Support Professional. If this is
> critical, I'd recommend contacting PSS and opening a Support incident to
> troubleshoot this further. If you need any help in this regard, please let
> me know.
> I am standing by for your response.
> Regards,
> Michael Shao
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
>|||Hi Andrew,
Thanks for your response. Please perform the following tests on your side
so that I can narrow down this issue.
1. Please perform the problematic backup job manually to see if the problem
also occurs.
2. Have you tried the suggestions in my previous post? Please try to use
the file path instead of the network share name for the backup file(s) on
the destination computer. Can you backup the transaction logs?
3. Please try to change the Write Policy for the RAID controller from
Writethru to Writeback. Does it solve your problem?
If not,please provide the following information so that I can perform
further research.
1. When the backup problem occurred, could you connect to the destination
server using the server name?
2. You wrote "it is only the bigger ones (over 1GB) that seem to give the
error." I am unable to find related information on this in the sqldiag.txt
file. Why do you think so, can you describe it in detail?
3.Do you mean that you are unable to backup transaction logs (over 1GB)
using the server name in any situation?
I am standing by for your response.
Thank you,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||Michael,
Good morning and thanks for your last reply.
1. Yes, the error happens when a manual backup is done.
2. I backed up upto the local drive E:\ - is this what you mean by file
path - or do you mean mapping a drive letter to the share and backing up to
the drive letter?
3. I have changed the RAID system on the NAS from RAID5 to RAID1, I am
waiting for results but it looks good so far, in that a manual backup has
completed where it did not before the conversion. I will know tommorow for
good.
If this does solve the problem - it surely means that there is no
handshaking/communication between two computers on the network - so one can
easily "swamp" the other with data and get an error message. I would have
thought MS Windows was able to cope with this sinario - any comments?
I will let you know tommorow when my nightly backup has completed, I am
quietly hopeful.
Thanks again
Andrew.
"Michael Shao [MSFT]" <v-yshao@.online.microsoft.com> wrote in message
news:7rULUm8tDHA.984@.cpmsftngxa06.phx.gbl...
> Hi Andrew,
> Thanks for your response. Please perform the following tests on your side
> so that I can narrow down this issue.
> 1. Please perform the problematic backup job manually to see if the
problem
> also occurs.
> 2. Have you tried the suggestions in my previous post? Please try to use
> the file path instead of the network share name for the backup file(s) on
> the destination computer. Can you backup the transaction logs?
> 3. Please try to change the Write Policy for the RAID controller from
> Writethru to Writeback. Does it solve your problem?
> If not,please provide the following information so that I can perform
> further research.
> 1. When the backup problem occurred, could you connect to the destination
> server using the server name?
> 2. You wrote "it is only the bigger ones (over 1GB) that seem to give the
> error." I am unable to find related information on this in the sqldiag.txt
> file. Why do you think so, can you describe it in detail?
> 3.Do you mean that you are unable to backup transaction logs (over 1GB)
> using the server name in any situation?
> I am standing by for your response.
> Thank you,
> Michael Shao
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
>|||Hi Andrew,
Thanks for your response. I am glad to hear that the manual backup works
after the conversion. Hope the backup job also works fine.
The file path which I mentioned in my previous post indicated the local
path. Generally, it is better to backup the database to the local machine
and run some jobs to copy the backup files to the remote machine. In my
opinion, it is a safer solution.
Also, I am not quite clear your concerns about handshaking/communication on
the network. What does the handshaking/communication indicate? What do you
mean by " swamp"? Can you describe your concerns in detail?
I am standing by for the result on your side.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||Michael,
Thanks for your help - all seems to work now I have changed the NAS to RAID
0 from RAID 5.
My concerns are as you mention - surely one windows computer on the network
cannot "swamp" another - surely there is communication between the
computers - like hold on a minute with that data while I just commit what I
have to disk - ok ready now please send the next chunk.
Andrew.
"Michael Shao [MSFT]" <v-yshao@.online.microsoft.com> wrote in message
news:Aq%23G2XLuDHA.1532@.cpmsftngxa06.phx.gbl...
> Hi Andrew,
> Thanks for your response. I am glad to hear that the manual backup works
> after the conversion. Hope the backup job also works fine.
> The file path which I mentioned in my previous post indicated the local
> path. Generally, it is better to backup the database to the local machine
> and run some jobs to copy the backup files to the remote machine. In my
> opinion, it is a safer solution.
> Also, I am not quite clear your concerns about handshaking/communication
on
> the network. What does the handshaking/communication indicate? What do you
> mean by " swamp"? Can you describe your concerns in detail?
> I am standing by for the result on your side.
> Regards,
> Michael Shao
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
>|||Hi Andrew,
Thanks for your update. It is great that the backup job also works fine.
Generally, when taking backup copy on the network, some protocol will be
used. There are certain Timout and Retry mechanism defined in the protocol.
If there is still no response from the target after using the Timout and
Retry mechanism, the error will occur.
Thanks for using MSDN newsgroup.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Error 3624

I see in my SQL2K Server logs the following error, at least once a day if
not more often:
Error: 3624, Severity: 20, State: 1.
SQL Server Assertion: File: <recbase.cpp>, line=1378
Failed Assertion = 'm_offBeginVar < m_SizeRec'.
DBCC CHECKDB reports all is well with all of the databases on this server.
The fix outlined in KB317852 gives (almost) the exact same message, but it
says that was fixed in SP3 and I'm using SP3a, which was installed *before*
any of my own databases were created. I have an Access 97 Front End, with
the Default Record Locking set to No Locks. KB827714 seems to address a
similar issue. Does this sound like the problem? Is it something serious
where I should consider the 827714 hotfix? Or should I just ignore it and
wait for the next SP?
Is your situation as described in the symptoms section of the KB?
Tunji
"Ron Hinds" <__NoSpam@.__NoSpamramac.com> wrote in message news:ub5LMGjsEHA.2136@.TK2MSFTNGP11.phx.gbl...
I see in my SQL2K Server logs the following error, at least once a day if
not more often:
Error: 3624, Severity: 20, State: 1.
SQL Server Assertion: File: <recbase.cpp>, line=1378
Failed Assertion = 'm_offBeginVar < m_SizeRec'.
DBCC CHECKDB reports all is well with all of the databases on this server.
The fix outlined in KB317852 gives (almost) the exact same message, but it
says that was fixed in SP3 and I'm using SP3a, which was installed *before*
any of my own databases were created. I have an Access 97 Front End, with
the Default Record Locking set to No Locks. KB827714 seems to address a
similar issue. Does this sound like the problem? Is it something serious
where I should consider the 827714 hotfix? Or should I just ignore it and
wait for the next SP?
|||Yes. The two errors are exactly as described. I looked at the dump file and the query was a SELECT against a table with historical data only (in this instance anyway). Basically it is a sales history table and the query sums the sales for a particular salesman month to date. The table is only updated during the end of day processing, when no one else is using he system.
"TJ" <tunj@.hotmail.com> wrote in message news:uzWMgSlsEHA.2196@.TK2MSFTNGP14.phx.gbl...
Is your situation as described in the symptoms section of the KB?
Tunji
"Ron Hinds" <__NoSpam@.__NoSpamramac.com> wrote in message news:ub5LMGjsEHA.2136@.TK2MSFTNGP11.phx.gbl...
I see in my SQL2K Server logs the following error, at least once a day if
not more often:
Error: 3624, Severity: 20, State: 1.
SQL Server Assertion: File: <recbase.cpp>, line=1378
Failed Assertion = 'm_offBeginVar < m_SizeRec'.
DBCC CHECKDB reports all is well with all of the databases on this server.
The fix outlined in KB317852 gives (almost) the exact same message, but it
says that was fixed in SP3 and I'm using SP3a, which was installed *before*
any of my own databases were created. I have an Access 97 Front End, with
the Default Record Locking set to No Locks. KB827714 seems to address a
similar issue. Does this sound like the problem? Is it something serious
where I should consider the 827714 hotfix? Or should I just ignore it and
wait for the next SP?

Error 3624

I see in my SQL2K Server logs the following error, at least once a day if
not more often:
Error: 3624, Severity: 20, State: 1.
SQL Server Assertion: File: <recbase.cpp>, line=1378
Failed Assertion = 'm_offBeginVar < m_SizeRec'.
DBCC CHECKDB reports all is well with all of the databases on this server.
The fix outlined in KB317852 gives (almost) the exact same message, but it
says that was fixed in SP3 and I'm using SP3a, which was installed *before*
any of my own databases were created. I have an Access 97 Front End, with
the Default Record Locking set to No Locks. KB827714 seems to address a
similar issue. Does this sound like the problem? Is it something serious
where I should consider the 827714 hotfix? Or should I just ignore it and
wait for the next SP?Is your situation as described in the symptoms section of the KB?
Tunji
"Ron Hinds" <__NoSpam@.__NoSpamramac.com> wrote in message news:ub5LMGjsEHA.2
136@.TK2MSFTNGP11.phx.gbl...
I see in my SQL2K Server logs the following error, at least once a day if
not more often:
Error: 3624, Severity: 20, State: 1.
SQL Server Assertion: File: <recbase.cpp>, line=1378
Failed Assertion = 'm_offBeginVar < m_SizeRec'.
DBCC CHECKDB reports all is well with all of the databases on this server.
The fix outlined in KB317852 gives (almost) the exact same message, but it
says that was fixed in SP3 and I'm using SP3a, which was installed *before*
any of my own databases were created. I have an Access 97 Front End, with
the Default Record Locking set to No Locks. KB827714 seems to address a
similar issue. Does this sound like the problem? Is it something serious
where I should consider the 827714 hotfix? Or should I just ignore it and
wait for the next SP?|||Yes. The two errors are exactly as described. I looked at the dump file and
the query was a SELECT against a table with historical data only (in this in
stance anyway). Basically it is a sales history table and the query sums the
sales for a particular salesman month to date. The table is only updated du
ring the end of day processing, when no one else is using he system.
"TJ" <tunj@.hotmail.com> wrote in message news:uzWMgSlsEHA.2196@.TK2MSFTNGP14.
phx.gbl...
Is your situation as described in the symptoms section of the KB?
Tunji
"Ron Hinds" <__NoSpam@.__NoSpamramac.com> wrote in message news:ub5LMGjsEHA.2
136@.TK2MSFTNGP11.phx.gbl...
I see in my SQL2K Server logs the following error, at least once a day if
not more often:
Error: 3624, Severity: 20, State: 1.
SQL Server Assertion: File: <recbase.cpp>, line=1378
Failed Assertion = 'm_offBeginVar < m_SizeRec'.
DBCC CHECKDB reports all is well with all of the databases on this server.
The fix outlined in KB317852 gives (almost) the exact same message, but it
says that was fixed in SP3 and I'm using SP3a, which was installed *before*
any of my own databases were created. I have an Access 97 Front End, with
the Default Record Locking set to No Locks. KB827714 seems to address a
similar issue. Does this sound like the problem? Is it something serious
where I should consider the 827714 hotfix? Or should I just ignore it and
wait for the next SP?

Error 3621

For some reason I'm getting the following error on my MS2000 MSSQl
server. THe message is being written into my logs on the server.
MSSQL Error Msg 3621 The statement has been terminated
THis is then followed by the information message
Connected to DB
THis continues in a over and over again. My DB was working
fine and I could use the query analyzer, now however I cannot
query anything in the DB.
Any help would be great. I really dont want to reinstall this
as a solution.
TIA
dogdog
This message is usually preceded by another message indicating the cause the
error. Are these messages in the SQL Server error log or in a log generated
by your application?
Hope this helps.
Dan Guzman
SQL Server MVP
<dogdog@.noemail.com> wrote in message
news:pan.2006.03.25.15.15.20.194339@.noemail.com...
> For some reason I'm getting the following error on my MS2000 MSSQl
> server. THe message is being written into my logs on the server.
> MSSQL Error Msg 3621 The statement has been terminated
> THis is then followed by the information message
> Connected to DB
> THis continues in a over and over again. My DB was working
> fine and I could use the query analyzer, now however I cannot
> query anything in the DB.
> Any help would be great. I really dont want to reinstall this
> as a solution.
> TIA
> dogdog
|||On Sat, 25 Mar 2006 09:32:12 +0000, Dan Guzman wrote:

> This message is usually preceded by another message indicating the cause the
> error. Are these messages in the SQL Server error log or in a log generated
> by your application?
The next message after the error 3621 is Statement has been terminated
and is then followed by an information message
stating "connected to db" This sequence just keeps going and going
over and over.
Hope that helps. Because it means absolutely nothing to me.
tks
dogdog
|||So these messages are in a log generated by your application? In that case,
it appears your application is reporting only the 3621 warning message and
not the preceding error that caused the statement to be terminated.
For example, below are the messages that are displayed by Query Analyzer
when I get a primary key violation:
Server: Msg 2627, Level 14, State 1, Line 1
Violation of PRIMARY KEY constraint 'PK_Table1'. Cannot insert duplicate key
in object 'Table1'.
The statement has been terminated.
If you have no control over the application logging behavior, I suggest you
run a Profiler trace to capture error events. This should help you identify
the problem SQL statements.
Hope this helps.
Dan Guzman
SQL Server MVP
<dogdog@.noemail.com> wrote in message
news:pan.2006.03.25.20.57.13.800017@.noemail.com...
> On Sat, 25 Mar 2006 09:32:12 +0000, Dan Guzman wrote:
>
> The next message after the error 3621 is Statement has been terminated
> and is then followed by an information message
> stating "connected to db" This sequence just keeps going and going
> over and over.
> Hope that helps. Because it means absolutely nothing to me.
> tks
> dogdog
|||On Sun, 26 Mar 2006 06:27:38 +0000, Dan Guzman wrote:
First off thanks for taking your time on this and explaining things to
me a novice with mssql.

> So these messages are in a log generated by your application? In that case,
> it appears your application is reporting only the 3621 warning message and
> not the preceding error that caused the statement to be terminated.
>
Yes they are being written to the system log by the mssql server. I
guess that was the best idea for this setup rather than having numerous
logs.

> For example, below are the messages that are displayed by Query Analyzer
> when I get a primary key violation:
> Server: Msg 2627, Level 14, State 1, Line 1
> Violation of PRIMARY KEY constraint 'PK_Table1'. Cannot insert duplicate key
> in object 'Table1'.
> The statement has been terminated.
> If you have no control over the application logging behavior, I suggest you
> run a Profiler trace to capture error events. This should help you identify
> the problem SQL statements.
It seems as if the last query ran is "stuck" for lack of a better
understanding and just keeps querying. So it runs (without user
interaction for some reason) then reports the Error 3621 Statement
has been terminated. Then waits and reconnects to the server and
does it again. Seems crazy but I didnt make this stuff and it
makes it really hard to figure out when you inherit something like
this. Unfortunately there are no other logs to help in troubleshooting
and I want to avoid reinstalling the entire database. Luckily it
just came online and we just started testing it (i.e. sending
queries on test data) so if it does come down to reloading there
will be nothing lost. I just want to avoid that.
Thanks again for your help. If you have any other ideas I'll be glad
to try them out. I'm going to give the Profiler trace idea a shot.
Hopefully it will lead to something.

Error 3621

For some reason I'm getting the following error on my MS2000 MSSQl
server. THe message is being written into my logs on the server.
MSSQL Error Msg 3621 The statement has been terminated
THis is then followed by the information message
Connected to DB
THis continues in a over and over again. My DB was working
fine and I could use the query analyzer, now however I cannot
query anything in the DB.
Any help would be great. I really dont want to reinstall this
as a solution.
TIA
dogdogThis message is usually preceded by another message indicating the cause the
error. Are these messages in the SQL Server error log or in a log generated
by your application?
Hope this helps.
Dan Guzman
SQL Server MVP
<dogdog@.noemail.com> wrote in message
news:pan.2006.03.25.15.15.20.194339@.noemail.com...
> For some reason I'm getting the following error on my MS2000 MSSQl
> server. THe message is being written into my logs on the server.
> MSSQL Error Msg 3621 The statement has been terminated
> THis is then followed by the information message
> Connected to DB
> THis continues in a over and over again. My DB was working
> fine and I could use the query analyzer, now however I cannot
> query anything in the DB.
> Any help would be great. I really dont want to reinstall this
> as a solution.
> TIA
> dogdog|||On Sat, 25 Mar 2006 09:32:12 +0000, Dan Guzman wrote:

> This message is usually preceded by another message indicating the cause t
he
> error. Are these messages in the SQL Server error log or in a log generat
ed
> by your application?
The next message after the error 3621 is Statement has been terminated
and is then followed by an information message
stating "connected to db" This sequence just keeps going and going
over and over.
Hope that helps. Because it means absolutely nothing to me.
tks
dogdog|||So these messages are in a log generated by your application? In that case,
it appears your application is reporting only the 3621 warning message and
not the preceding error that caused the statement to be terminated.
For example, below are the messages that are displayed by Query Analyzer
when I get a primary key violation:
Server: Msg 2627, Level 14, State 1, Line 1
Violation of PRIMARY KEY constraint 'PK_Table1'. Cannot insert duplicate key
in object 'Table1'.
The statement has been terminated.
If you have no control over the application logging behavior, I suggest you
run a Profiler trace to capture error events. This should help you identify
the problem SQL statements.
Hope this helps.
Dan Guzman
SQL Server MVP
<dogdog@.noemail.com> wrote in message
news:pan.2006.03.25.20.57.13.800017@.noemail.com...
> On Sat, 25 Mar 2006 09:32:12 +0000, Dan Guzman wrote:
>
> The next message after the error 3621 is Statement has been terminated
> and is then followed by an information message
> stating "connected to db" This sequence just keeps going and going
> over and over.
> Hope that helps. Because it means absolutely nothing to me.
> tks
> dogdog|||On Sun, 26 Mar 2006 06:27:38 +0000, Dan Guzman wrote:
First off thanks for taking your time on this and explaining things to
me a novice with mssql.

> So these messages are in a log generated by your application? In that cas
e,
> it appears your application is reporting only the 3621 warning message and
> not the preceding error that caused the statement to be terminated.
>
Yes they are being written to the system log by the mssql server. I
guess that was the best idea for this setup rather than having numerous
logs.

> For example, below are the messages that are displayed by Query Analyzer
> when I get a primary key violation:
> Server: Msg 2627, Level 14, State 1, Line 1
> Violation of PRIMARY KEY constraint 'PK_Table1'. Cannot insert duplicate k
ey
> in object 'Table1'.
> The statement has been terminated.
> If you have no control over the application logging behavior, I suggest yo
u
> run a Profiler trace to capture error events. This should help you identi
fy
> the problem SQL statements.
It seems as if the last query ran is "stuck" for lack of a better
understanding and just keeps querying. So it runs (without user
interaction for some reason) then reports the Error 3621 Statement
has been terminated. Then waits and reconnects to the server and
does it again. Seems crazy but I didnt make this stuff and it
makes it really hard to figure out when you inherit something like
this. Unfortunately there are no other logs to help in troubleshooting
and I want to avoid reinstalling the entire database. Luckily it
just came online and we just started testing it (i.e. sending
queries on test data) so if it does come down to reloading there
will be nothing lost. I just want to avoid that.
Thanks again for your help. If you have any other ideas I'll be glad
to try them out. I'm going to give the Profiler trace idea a shot.
Hopefully it will lead to something.