We have a reporting database that end users run ad-hoc queries against (SQL
Server 2000 SP 4 running on Windows 2000). Periodically, we'll get the
following error message:
Error: 9002, Severity: 17, State: 6
The log file for database 'tempdb' is full. Back up the transaction log for
the database to free up some log space.
When I track down the user associated with the Event Log message, he/she is
running a huge query that needs better selection criteria, but I don't
believe that the tempdb log is truely out of space. We have plenty of disk
space, and have gotten this message with tempdb log set to unrestricted and
with a limit of 15 GB.
Question: Is this a sql server bug or related to an i/o problem, because it
really isn't a true tempdb log full condition. Does this impact all users
using tempdb (I would think so) and any suggestions on how to prevent this?
Thanks,
DanDan,
This is not a bug. It is truly a tempdb log full alert. It does not matter
how much space you have because you are limiting the log to 15 GB. It is ver
y
much possible for the log to be full on a reporting database. Remember, all
sorting, agregations and temp tables are created in the tempdb.
I don't think there is a right answer for the size, you will have to
increase it and watch it and increase it again as needed.
hth
DeeJay
"Dan H" wrote:
> We have a reporting database that end users run ad-hoc queries against (SQ
L
> Server 2000 SP 4 running on Windows 2000). Periodically, we'll get the
> following error message:
> Error: 9002, Severity: 17, State: 6
> The log file for database 'tempdb' is full. Back up the transaction log fo
r
> the database to free up some log space.
> When I track down the user associated with the Event Log message, he/she i
s
> running a huge query that needs better selection criteria, but I don't
> believe that the tempdb log is truely out of space. We have plenty of dis
k
> space, and have gotten this message with tempdb log set to unrestricted an
d
> with a limit of 15 GB.
> Question: Is this a sql server bug or related to an i/o problem, because
it
> really isn't a true tempdb log full condition. Does this impact all users
> using tempdb (I would think so) and any suggestions on how to prevent this
?
> Thanks,
> Dan
Showing posts with label queries. Show all posts
Showing posts with label queries. Show all posts
Tuesday, March 27, 2012
Error 9002, tempdb log full
We have a reporting database that end users run ad-hoc queries against (SQL
Server 2000 SP 4 running on Windows 2000). Periodically, we'll get the
following error message:
Error: 9002, Severity: 17, State: 6
The log file for database 'tempdb' is full. Back up the transaction log for
the database to free up some log space.
When I track down the user associated with the Event Log message, he/she is
running a huge query that needs better selection criteria, but I don't
believe that the tempdb log is truely out of space. We have plenty of disk
space, and have gotten this message with tempdb log set to unrestricted and
with a limit of 15 GB.
Question: Is this a sql server bug or related to an i/o problem, because it
really isn't a true tempdb log full condition. Does this impact all users
using tempdb (I would think so) and any suggestions on how to prevent this?
Thanks,
Dan
Dan,
This is not a bug. It is truly a tempdb log full alert. It does not matter
how much space you have because you are limiting the log to 15 GB. It is very
much possible for the log to be full on a reporting database. Remember, all
sorting, agregations and temp tables are created in the tempdb.
I don't think there is a right answer for the size, you will have to
increase it and watch it and increase it again as needed.
hth
DeeJay
"Dan H" wrote:
> We have a reporting database that end users run ad-hoc queries against (SQL
> Server 2000 SP 4 running on Windows 2000). Periodically, we'll get the
> following error message:
> Error: 9002, Severity: 17, State: 6
> The log file for database 'tempdb' is full. Back up the transaction log for
> the database to free up some log space.
> When I track down the user associated with the Event Log message, he/she is
> running a huge query that needs better selection criteria, but I don't
> believe that the tempdb log is truely out of space. We have plenty of disk
> space, and have gotten this message with tempdb log set to unrestricted and
> with a limit of 15 GB.
> Question: Is this a sql server bug or related to an i/o problem, because it
> really isn't a true tempdb log full condition. Does this impact all users
> using tempdb (I would think so) and any suggestions on how to prevent this?
> Thanks,
> Dan
Server 2000 SP 4 running on Windows 2000). Periodically, we'll get the
following error message:
Error: 9002, Severity: 17, State: 6
The log file for database 'tempdb' is full. Back up the transaction log for
the database to free up some log space.
When I track down the user associated with the Event Log message, he/she is
running a huge query that needs better selection criteria, but I don't
believe that the tempdb log is truely out of space. We have plenty of disk
space, and have gotten this message with tempdb log set to unrestricted and
with a limit of 15 GB.
Question: Is this a sql server bug or related to an i/o problem, because it
really isn't a true tempdb log full condition. Does this impact all users
using tempdb (I would think so) and any suggestions on how to prevent this?
Thanks,
Dan
Dan,
This is not a bug. It is truly a tempdb log full alert. It does not matter
how much space you have because you are limiting the log to 15 GB. It is very
much possible for the log to be full on a reporting database. Remember, all
sorting, agregations and temp tables are created in the tempdb.
I don't think there is a right answer for the size, you will have to
increase it and watch it and increase it again as needed.
hth
DeeJay
"Dan H" wrote:
> We have a reporting database that end users run ad-hoc queries against (SQL
> Server 2000 SP 4 running on Windows 2000). Periodically, we'll get the
> following error message:
> Error: 9002, Severity: 17, State: 6
> The log file for database 'tempdb' is full. Back up the transaction log for
> the database to free up some log space.
> When I track down the user associated with the Event Log message, he/she is
> running a huge query that needs better selection criteria, but I don't
> believe that the tempdb log is truely out of space. We have plenty of disk
> space, and have gotten this message with tempdb log set to unrestricted and
> with a limit of 15 GB.
> Question: Is this a sql server bug or related to an i/o problem, because it
> really isn't a true tempdb log full condition. Does this impact all users
> using tempdb (I would think so) and any suggestions on how to prevent this?
> Thanks,
> Dan
Error 9002, tempdb log full
We have a reporting database that end users run ad-hoc queries against (SQL
Server 2000 SP 4 running on Windows 2000). Periodically, we'll get the
following error message:
Error: 9002, Severity: 17, State: 6
The log file for database 'tempdb' is full. Back up the transaction log for
the database to free up some log space.
When I track down the user associated with the Event Log message, he/she is
running a huge query that needs better selection criteria, but I don't
believe that the tempdb log is truely out of space. We have plenty of disk
space, and have gotten this message with tempdb log set to unrestricted and
with a limit of 15 GB.
Question: Is this a sql server bug or related to an i/o problem, because it
really isn't a true tempdb log full condition. Does this impact all users
using tempdb (I would think so) and any suggestions on how to prevent this?
Thanks,
DanDan,
This is not a bug. It is truly a tempdb log full alert. It does not matter
how much space you have because you are limiting the log to 15 GB. It is very
much possible for the log to be full on a reporting database. Remember, all
sorting, agregations and temp tables are created in the tempdb.
I don't think there is a right answer for the size, you will have to
increase it and watch it and increase it again as needed.
hth
DeeJay
"Dan H" wrote:
> We have a reporting database that end users run ad-hoc queries against (SQL
> Server 2000 SP 4 running on Windows 2000). Periodically, we'll get the
> following error message:
> Error: 9002, Severity: 17, State: 6
> The log file for database 'tempdb' is full. Back up the transaction log for
> the database to free up some log space.
> When I track down the user associated with the Event Log message, he/she is
> running a huge query that needs better selection criteria, but I don't
> believe that the tempdb log is truely out of space. We have plenty of disk
> space, and have gotten this message with tempdb log set to unrestricted and
> with a limit of 15 GB.
> Question: Is this a sql server bug or related to an i/o problem, because it
> really isn't a true tempdb log full condition. Does this impact all users
> using tempdb (I would think so) and any suggestions on how to prevent this?
> Thanks,
> Dan
Server 2000 SP 4 running on Windows 2000). Periodically, we'll get the
following error message:
Error: 9002, Severity: 17, State: 6
The log file for database 'tempdb' is full. Back up the transaction log for
the database to free up some log space.
When I track down the user associated with the Event Log message, he/she is
running a huge query that needs better selection criteria, but I don't
believe that the tempdb log is truely out of space. We have plenty of disk
space, and have gotten this message with tempdb log set to unrestricted and
with a limit of 15 GB.
Question: Is this a sql server bug or related to an i/o problem, because it
really isn't a true tempdb log full condition. Does this impact all users
using tempdb (I would think so) and any suggestions on how to prevent this?
Thanks,
DanDan,
This is not a bug. It is truly a tempdb log full alert. It does not matter
how much space you have because you are limiting the log to 15 GB. It is very
much possible for the log to be full on a reporting database. Remember, all
sorting, agregations and temp tables are created in the tempdb.
I don't think there is a right answer for the size, you will have to
increase it and watch it and increase it again as needed.
hth
DeeJay
"Dan H" wrote:
> We have a reporting database that end users run ad-hoc queries against (SQL
> Server 2000 SP 4 running on Windows 2000). Periodically, we'll get the
> following error message:
> Error: 9002, Severity: 17, State: 6
> The log file for database 'tempdb' is full. Back up the transaction log for
> the database to free up some log space.
> When I track down the user associated with the Event Log message, he/she is
> running a huge query that needs better selection criteria, but I don't
> believe that the tempdb log is truely out of space. We have plenty of disk
> space, and have gotten this message with tempdb log set to unrestricted and
> with a limit of 15 GB.
> Question: Is this a sql server bug or related to an i/o problem, because it
> really isn't a true tempdb log full condition. Does this impact all users
> using tempdb (I would think so) and any suggestions on how to prevent this?
> Thanks,
> Dan
Wednesday, March 21, 2012
error 7405
I have created a stored procedure wich queries a linked ORACLE database. When
I try to save the procedure I get the following error
Heterogeneous queries require the ANSI_NULLS and ANSI_WARNINGS options to be
set for the connection. This ensures consistent query semantics. Enable these
options and then reissue your query.
I have put SET ANSI_WARNINGS ON as the first line of the procedure with no
help.
Are there any suggestions?
Jim Capehart
The connection creating the stored procedure needs to have
the settings on. So you'd want to create the stored
procedure using something along the lines of:
SET ANSI_NULLS ON
GO
SET ANSI_WARNINGS ON
GO
CREATE PROCEDURE YourStoredProc...etc.
-Sue
On Fri, 17 Dec 2004 08:11:02 -0800, Jim Capehart
<JimCapehart@.discussions.microsoft.com> wrote:
>I have created a stored procedure wich queries a linked ORACLE database. When
>I try to save the procedure I get the following error
>Heterogeneous queries require the ANSI_NULLS and ANSI_WARNINGS options to be
>set for the connection. This ensures consistent query semantics. Enable these
>options and then reissue your query.
> I have put SET ANSI_WARNINGS ON as the first line of the procedure with no
>help.
>Are there any suggestions?
>Jim Capehart
|||Guys,
This doesn't necessarily work. If your not happ y with adding these
settings to the the server as a whole then try using the ISQL window to
create the procedure.
Be sure to make a copy of the oprginal (just in case) but this will
allow the SET command to intigated at the top of he procedure.
Hope this helps.
JohnT-A
Posted via http://www.webservertalk.com
View this thread: http://www.webservertalk.com/message654588.html
I try to save the procedure I get the following error
Heterogeneous queries require the ANSI_NULLS and ANSI_WARNINGS options to be
set for the connection. This ensures consistent query semantics. Enable these
options and then reissue your query.
I have put SET ANSI_WARNINGS ON as the first line of the procedure with no
help.
Are there any suggestions?
Jim Capehart
The connection creating the stored procedure needs to have
the settings on. So you'd want to create the stored
procedure using something along the lines of:
SET ANSI_NULLS ON
GO
SET ANSI_WARNINGS ON
GO
CREATE PROCEDURE YourStoredProc...etc.
-Sue
On Fri, 17 Dec 2004 08:11:02 -0800, Jim Capehart
<JimCapehart@.discussions.microsoft.com> wrote:
>I have created a stored procedure wich queries a linked ORACLE database. When
>I try to save the procedure I get the following error
>Heterogeneous queries require the ANSI_NULLS and ANSI_WARNINGS options to be
>set for the connection. This ensures consistent query semantics. Enable these
>options and then reissue your query.
> I have put SET ANSI_WARNINGS ON as the first line of the procedure with no
>help.
>Are there any suggestions?
>Jim Capehart
|||Guys,
This doesn't necessarily work. If your not happ y with adding these
settings to the the server as a whole then try using the ISQL window to
create the procedure.
Be sure to make a copy of the oprginal (just in case) but this will
allow the SET command to intigated at the top of he procedure.
Hope this helps.
JohnT-A
Posted via http://www.webservertalk.com
View this thread: http://www.webservertalk.com/message654588.html
error 7399, OLE DB-errorrtrace, opendatasource
I would like to read data from an sql server using ad hoc queries in two seperate sessions (opendatasource). However, when I try to access both databanks the following error is generated:
Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile 3
Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der Provider hat keine Informationen zu dem Fehler bereitgestellt.
OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IOpenRowset::OpenRowset returned 0x80004005: Der Provider hat keine Informationen zu dem Fehler bereitgestellt.].
thanks
Tulpe,
This looks like your SQL Server is actually passing you through to a linked
server for a Jet database (Access). Is that what is happening? If so,
there are a few KB articles that may help.
http://support.microsoft.com/default...b;en-us;296711
http://support.microsoft.com/default...b;en-us;818182
http://support.microsoft.com/default...b;en-us;814398
http://support.microsoft.com/default...b;en-us;285833
Russell Fields
"Tulpe" <anonymous@.discussions.microsoft.com> wrote in message
news:A6F5B481-5BAE-4DEB-AF78-D6147D5C1FB7@.microsoft.com...
> I would like to read data from an sql server using ad hoc queries in two
seperate sessions (opendatasource). However, when I try to access both
databanks the following error is generated:
> Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile 3
> Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der
Provider hat keine Informationen zu dem Fehler bereitgestellt.
> OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
IOpenRowset::OpenRowset returned 0x80004005: Der Provider hat keine
Informationen zu dem Fehler bereitgestellt.].
> thanks
Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile 3
Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der Provider hat keine Informationen zu dem Fehler bereitgestellt.
OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IOpenRowset::OpenRowset returned 0x80004005: Der Provider hat keine Informationen zu dem Fehler bereitgestellt.].
thanks
Tulpe,
This looks like your SQL Server is actually passing you through to a linked
server for a Jet database (Access). Is that what is happening? If so,
there are a few KB articles that may help.
http://support.microsoft.com/default...b;en-us;296711
http://support.microsoft.com/default...b;en-us;818182
http://support.microsoft.com/default...b;en-us;814398
http://support.microsoft.com/default...b;en-us;285833
Russell Fields
"Tulpe" <anonymous@.discussions.microsoft.com> wrote in message
news:A6F5B481-5BAE-4DEB-AF78-D6147D5C1FB7@.microsoft.com...
> I would like to read data from an sql server using ad hoc queries in two
seperate sessions (opendatasource). However, when I try to access both
databanks the following error is generated:
> Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile 3
> Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der
Provider hat keine Informationen zu dem Fehler bereitgestellt.
> OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
IOpenRowset::OpenRowset returned 0x80004005: Der Provider hat keine
Informationen zu dem Fehler bereitgestellt.].
> thanks
error 7399, OLE DB-errorrtrace, opendatasource
I would like to read data from an sql server using ad hoc queries in two seperate sessions (opendatasource). However, when I try to access both databanks the following error is generated
Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile
Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der Provider hat keine Informationen zu dem Fehler bereitgestellt
OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IOpenRowset::OpenRowset returned 0x80004005: Der Provider hat keine Informationen zu dem Fehler bereitgestellt.]
thanksTulpe,
This looks like your SQL Server is actually passing you through to a linked
server for a Jet database (Access). Is that what is happening? If so,
there are a few KB articles that may help.
http://support.microsoft.com/default.aspx?scid=kb;en-us;296711
http://support.microsoft.com/default.aspx?scid=kb;en-us;818182
http://support.microsoft.com/default.aspx?scid=kb;en-us;814398
http://support.microsoft.com/default.aspx?scid=kb;en-us;285833
Russell Fields
"Tulpe" <anonymous@.discussions.microsoft.com> wrote in message
news:A6F5B481-5BAE-4DEB-AF78-D6147D5C1FB7@.microsoft.com...
> I would like to read data from an sql server using ad hoc queries in two
seperate sessions (opendatasource). However, when I try to access both
databanks the following error is generated:
> Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile 3
> Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der
Provider hat keine Informationen zu dem Fehler bereitgestellt.
> OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
IOpenRowset::OpenRowset returned 0x80004005: Der Provider hat keine
Informationen zu dem Fehler bereitgestellt.].
> thankssql
Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile
Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der Provider hat keine Informationen zu dem Fehler bereitgestellt
OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IOpenRowset::OpenRowset returned 0x80004005: Der Provider hat keine Informationen zu dem Fehler bereitgestellt.]
thanksTulpe,
This looks like your SQL Server is actually passing you through to a linked
server for a Jet database (Access). Is that what is happening? If so,
there are a few KB articles that may help.
http://support.microsoft.com/default.aspx?scid=kb;en-us;296711
http://support.microsoft.com/default.aspx?scid=kb;en-us;818182
http://support.microsoft.com/default.aspx?scid=kb;en-us;814398
http://support.microsoft.com/default.aspx?scid=kb;en-us;285833
Russell Fields
"Tulpe" <anonymous@.discussions.microsoft.com> wrote in message
news:A6F5B481-5BAE-4DEB-AF78-D6147D5C1FB7@.microsoft.com...
> I would like to read data from an sql server using ad hoc queries in two
seperate sessions (opendatasource). However, when I try to access both
databanks the following error is generated:
> Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile 3
> Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der
Provider hat keine Informationen zu dem Fehler bereitgestellt.
> OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
IOpenRowset::OpenRowset returned 0x80004005: Der Provider hat keine
Informationen zu dem Fehler bereitgestellt.].
> thankssql
error 7399, OLE DB-errorrtrace, opendatasource
I would like to read data from an sql server using ad hoc queries in two sep
erate sessions (opendatasource). However, when I try to access both databan
ks the following error is generated:
Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile 3
Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der Prov
ider hat keine Informationen zu dem Fehler bereitgestellt.
OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IOpenRowse
t::OpenRowset returned 0x80004005: Der Provider hat keine Informationen zu
dem Fehler bereitgestellt.].
thanksTulpe,
This looks like your SQL Server is actually passing you through to a linked
server for a Jet database (Access). Is that what is happening? If so,
there are a few KB articles that may help.
http://support.microsoft.com/defaul...kb;en-us;296711
http://support.microsoft.com/defaul...kb;en-us;818182
http://support.microsoft.com/defaul...kb;en-us;814398
http://support.microsoft.com/defaul...kb;en-us;285833
Russell Fields
"Tulpe" <anonymous@.discussions.microsoft.com> wrote in message
news:A6F5B481-5BAE-4DEB-AF78-D6147D5C1FB7@.microsoft.com...
> I would like to read data from an sql server using ad hoc queries in two
seperate sessions (opendatasource). However, when I try to access both
databanks the following error is generated:
> Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile 3
> Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der
Provider hat keine Informationen zu dem Fehler bereitgestellt.
> OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
IOpenRowset::OpenRowset returned 0x80004005: Der Provider hat keine
Informationen zu dem Fehler bereitgestellt.].
> thanks
erate sessions (opendatasource). However, when I try to access both databan
ks the following error is generated:
Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile 3
Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der Prov
ider hat keine Informationen zu dem Fehler bereitgestellt.
OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IOpenRowse
t::OpenRowset returned 0x80004005: Der Provider hat keine Informationen zu
dem Fehler bereitgestellt.].
thanksTulpe,
This looks like your SQL Server is actually passing you through to a linked
server for a Jet database (Access). Is that what is happening? If so,
there are a few KB articles that may help.
http://support.microsoft.com/defaul...kb;en-us;296711
http://support.microsoft.com/defaul...kb;en-us;818182
http://support.microsoft.com/defaul...kb;en-us;814398
http://support.microsoft.com/defaul...kb;en-us;285833
Russell Fields
"Tulpe" <anonymous@.discussions.microsoft.com> wrote in message
news:A6F5B481-5BAE-4DEB-AF78-D6147D5C1FB7@.microsoft.com...
> I would like to read data from an sql server using ad hoc queries in two
seperate sessions (opendatasource). However, when I try to access both
databanks the following error is generated:
> Server: Nachr.-Nr. 7399, Schweregrad 16, Status 1, Zeile 3
> Der OLE DB-Provider 'Microsoft.Jet.OLEDB.4.0' meldete einen Fehler. Der
Provider hat keine Informationen zu dem Fehler bereitgestellt.
> OLE DB-Fehlertrace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
IOpenRowset::OpenRowset returned 0x80004005: Der Provider hat keine
Informationen zu dem Fehler bereitgestellt.].
> thanks
Friday, February 17, 2012
error 21770 on SQL2k upgrade
We just upgraded our SQL 7 to SQL 2000 SP3a and we have the following
happening
1. running about 10000-50000 queries through ODBC blows the machine up
completely. Have to power off and on to get it back. This same code
ran fine on SQL 7 before the upgrade. It doesn't blow up at the same
number of queries or on the same data and varies widely on when it
blows up in this process.
2. when we go to properties on any of the databases we get an error
21770.
Specifically,
Error 21770 [SQL-DMO] The name 'null' was not found in the
specified collection.
Then when you hit OK on the subsequent properties screen, we get an
error 21266.
We have seen error 15457 in the logs at times as well.
DBCC checkdb on each database returns no errors. I am sure the 2
issues are related but I can find no solution to the problem(s)
anywhere.
Any help or ideas appreciated.Hi,
Prob 1:
the only prob i could think of is logging and the servers 'trunc. log. on
chkpt.' might be off or your recovery model is full and logs are not cleaned
up regularly.
cause generally people miss out the option as it appears in database
properties in sql 7 but in 2000 we have to explicitly set it to true by
sp_dboption
Prob 2:
have u checked for the object names im sure none has the name 'null'
is the database configured for replication cause the error 21266 is caused
in replication when it cannot publish the tables.
about 15457 error appears due to any configuration changes made in - Run the
RECONFIGURE
Regards,
MD
--
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.
--
"Russ Cobbe" <russc@.inline.net> wrote in message
news:80e8c028.0402111950.4e4eebf9@.posting.google.com...
> We just upgraded our SQL 7 to SQL 2000 SP3a and we have the following
> happening
> 1. running about 10000-50000 queries through ODBC blows the machine up
> completely. Have to power off and on to get it back. This same code
> ran fine on SQL 7 before the upgrade. It doesn't blow up at the same
> number of queries or on the same data and varies widely on when it
> blows up in this process.
> 2. when we go to properties on any of the databases we get an error
> 21770.
> Specifically,
> Error 21770 [SQL-DMO] The name 'null' was not found in the
> specified collection.
> Then when you hit OK on the subsequent properties screen, we get an
> error 21266.
> We have seen error 15457 in the logs at times as well.
> DBCC checkdb on each database returns no errors. I am sure the 2
> issues are related but I can find no solution to the problem(s)
> anywhere.
> Any help or ideas appreciated.
happening
1. running about 10000-50000 queries through ODBC blows the machine up
completely. Have to power off and on to get it back. This same code
ran fine on SQL 7 before the upgrade. It doesn't blow up at the same
number of queries or on the same data and varies widely on when it
blows up in this process.
2. when we go to properties on any of the databases we get an error
21770.
Specifically,
Error 21770 [SQL-DMO] The name 'null' was not found in the
specified collection.
Then when you hit OK on the subsequent properties screen, we get an
error 21266.
We have seen error 15457 in the logs at times as well.
DBCC checkdb on each database returns no errors. I am sure the 2
issues are related but I can find no solution to the problem(s)
anywhere.
Any help or ideas appreciated.Hi,
Prob 1:
the only prob i could think of is logging and the servers 'trunc. log. on
chkpt.' might be off or your recovery model is full and logs are not cleaned
up regularly.
cause generally people miss out the option as it appears in database
properties in sql 7 but in 2000 we have to explicitly set it to true by
sp_dboption
Prob 2:
have u checked for the object names im sure none has the name 'null'
is the database configured for replication cause the error 21266 is caused
in replication when it cannot publish the tables.
about 15457 error appears due to any configuration changes made in - Run the
RECONFIGURE
Regards,
MD
--
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.
--
"Russ Cobbe" <russc@.inline.net> wrote in message
news:80e8c028.0402111950.4e4eebf9@.posting.google.com...
> We just upgraded our SQL 7 to SQL 2000 SP3a and we have the following
> happening
> 1. running about 10000-50000 queries through ODBC blows the machine up
> completely. Have to power off and on to get it back. This same code
> ran fine on SQL 7 before the upgrade. It doesn't blow up at the same
> number of queries or on the same data and varies widely on when it
> blows up in this process.
> 2. when we go to properties on any of the databases we get an error
> 21770.
> Specifically,
> Error 21770 [SQL-DMO] The name 'null' was not found in the
> specified collection.
> Then when you hit OK on the subsequent properties screen, we get an
> error 21266.
> We have seen error 15457 in the logs at times as well.
> DBCC checkdb on each database returns no errors. I am sure the 2
> issues are related but I can find no solution to the problem(s)
> anywhere.
> Any help or ideas appreciated.
error 21770 on SQL2k upgrade
We just upgraded our SQL 7 to SQL 2000 SP3a and we have the following
happening
1. running about 10000-50000 queries through ODBC blows the machine up
completely. Have to power off and on to get it back. This same code
ran fine on SQL 7 before the upgrade. It doesn't blow up at the same
number of queries or on the same data and varies widely on when it
blows up in this process.
2. when we go to properties on any of the databases we get an error
21770.
Specifically,
Error 21770 [SQL-DMO] The name 'null' was not found in the
specified collection.
Then when you hit OK on the subsequent properties screen, we get an
error 21266.
We have seen error 15457 in the logs at times as well.
DBCC checkdb on each database returns no errors. I am sure the 2
issues are related but I can find no solution to the problem(s)
anywhere.
Any help or ideas appreciated.Hi,
Prob 1:
the only prob i could think of is logging and the servers 'trunc. log. on
chkpt.' might be off or your recovery model is full and logs are not cleaned
up regularly.
cause generally people miss out the option as it appears in database
properties in sql 7 but in 2000 we have to explicitly set it to true by
sp_dboption
Prob 2:
have u checked for the object names im sure none has the name 'null'
is the database configured for replication cause the error 21266 is caused
in replication when it cannot publish the tables.
about 15457 error appears due to any configuration changes made in - Run the
RECONFIGURE
Regards,
MD
--
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.
--
"Russ Cobbe" <russc@.inline.net> wrote in message
news:80e8c028.0402111950.4e4eebf9@.posting.google.com...
> We just upgraded our SQL 7 to SQL 2000 SP3a and we have the following
> happening
> 1. running about 10000-50000 queries through ODBC blows the machine up
> completely. Have to power off and on to get it back. This same code
> ran fine on SQL 7 before the upgrade. It doesn't blow up at the same
> number of queries or on the same data and varies widely on when it
> blows up in this process.
> 2. when we go to properties on any of the databases we get an error
> 21770.
> Specifically,
> Error 21770 [SQL-DMO] The name 'null' was not found in the
> specified collection.
> Then when you hit OK on the subsequent properties screen, we get an
> error 21266.
> We have seen error 15457 in the logs at times as well.
> DBCC checkdb on each database returns no errors. I am sure the 2
> issues are related but I can find no solution to the problem(s)
> anywhere.
> Any help or ideas appreciated.
happening
1. running about 10000-50000 queries through ODBC blows the machine up
completely. Have to power off and on to get it back. This same code
ran fine on SQL 7 before the upgrade. It doesn't blow up at the same
number of queries or on the same data and varies widely on when it
blows up in this process.
2. when we go to properties on any of the databases we get an error
21770.
Specifically,
Error 21770 [SQL-DMO] The name 'null' was not found in the
specified collection.
Then when you hit OK on the subsequent properties screen, we get an
error 21266.
We have seen error 15457 in the logs at times as well.
DBCC checkdb on each database returns no errors. I am sure the 2
issues are related but I can find no solution to the problem(s)
anywhere.
Any help or ideas appreciated.Hi,
Prob 1:
the only prob i could think of is logging and the servers 'trunc. log. on
chkpt.' might be off or your recovery model is full and logs are not cleaned
up regularly.
cause generally people miss out the option as it appears in database
properties in sql 7 but in 2000 we have to explicitly set it to true by
sp_dboption
Prob 2:
have u checked for the object names im sure none has the name 'null'
is the database configured for replication cause the error 21266 is caused
in replication when it cannot publish the tables.
about 15457 error appears due to any configuration changes made in - Run the
RECONFIGURE
Regards,
MD
--
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.
--
"Russ Cobbe" <russc@.inline.net> wrote in message
news:80e8c028.0402111950.4e4eebf9@.posting.google.com...
> We just upgraded our SQL 7 to SQL 2000 SP3a and we have the following
> happening
> 1. running about 10000-50000 queries through ODBC blows the machine up
> completely. Have to power off and on to get it back. This same code
> ran fine on SQL 7 before the upgrade. It doesn't blow up at the same
> number of queries or on the same data and varies widely on when it
> blows up in this process.
> 2. when we go to properties on any of the databases we get an error
> 21770.
> Specifically,
> Error 21770 [SQL-DMO] The name 'null' was not found in the
> specified collection.
> Then when you hit OK on the subsequent properties screen, we get an
> error 21266.
> We have seen error 15457 in the logs at times as well.
> DBCC checkdb on each database returns no errors. I am sure the 2
> issues are related but I can find no solution to the problem(s)
> anywhere.
> Any help or ideas appreciated.
Subscribe to:
Posts (Atom)