In SQL Server 2008 R2 a temp-table in a stored procedure is defined with 2 varchar fields of length 25 and 50 that are too short for some of the data that is inserted into them. So this error makes perfect sense:
Msg 8152, Level 16, State 14, Procedure XYZ, Line 48
String or binary data would be truncated.
The statement has been terminated.
The trouble is, this error has only just started occurring in our production environment, and this is causing problems. Our UAT environment has lots of data that could also trigger this error, but doesn't.
We could just lengthen the fields in the stored procedure, but we would like to understand what change or setting could have caused this error to start appearing in production. We checked ANSI_WARNINGS and they were FALSE in both environments.
Any ideas would be appreciated.
Related
I have a table with approx 400 rows of geographic data and I'm using the STWithin method to determine if a point exists within the boundary of one of those rows.
On my test server it works fine. However with the latest version of the dataset the query fails on the live server on one of those rows of data. If I exclude the row from the query then it succeeds.
The error is:
Msg 6522, Level 16, State 1, Line 3
A .NET Framework error occurred during execution of user-defined
routine or aggregate "geometry": System.ArgumentException: 24144:
This operation cannot be completed because the instance is not valid.
Use MakeValid to convert the instance to a valid instance. Note that MakeValid may cause the points of a geometry instance to shift slightly.
A simplified version of the query is:
DECLARE #Point GEOMETRY = GEOMETRY::Point(416420, 345058, 0)
SELECT *
FROM PolygonData
WHERE #Point.STWithin(GeoField) = 1
The test server is SQL Server 2012 (11.0.2100.60), the live server is SQL Server 2012 (11.0.6544.0).
I can't see why the same data would be succeeding on one server and failing on the other? Any help much appreciated, thanks.
It turns out that there is invalid data in the table. Adding this as an answer, but also adding a way to fix the data in the table.
update t
set g = g.MakeValid()
from dbo.yourTable as t
where t.g.STIsValid() = 0;
(replacing yourTable and g with the name of the actual table and column, respectively) By updating the bad data as a one time operation, you won't incur the overhead of calling MakeValid() at select time (as presumably reads are more frequent than writes). You could also implement something like the above for any subsequent data loads you do.
I ran into an error in Sql Server and after resolving it, I am looking for the reason why this was happening.
The situation is that I tried to alter a column in a table like this
Alter Table tblEmployee
Alter Column empDate Date
But while running this script, I get the error -
The statistics 'empDate' is dependent on column 'empDate'.
Msg 4922, Level 16, State 9, Line 1
ALTER TABLE ALTER COLUMN empDate failed because one or more objects access this column.
It turns out that this error was because of a statistic being referenced on this column. I have no script that explicitly creates a statistic, and the error occurred in the production environment, so it must have been auto-created. If it is auto-created, then why isn't Sql Server deleting it by itself? My error was resolved when I dropped the statistic.
I looked at other places and not able to find anything relevant.
I haven't looked hard at SQL statistics for a few versions, but back when, auto-generated statistics had fairly distinctive names (like "_WA_Sys_00000005_00000037"). If your statistics literally had the name "empDate", then it was almost certainly not and auto-created statistics, but something someone created deliberately.
I have a problem with the replication on my machine where I am stuck with a number of subscriptions showing in SSMS that do not exist. I have tried deleting them using the UI in SSMS and also using some T-SQL...but no luck. The publications don't even exist any more (they were on the same machine).
Any ideas on how I could remove them?
More info:
This is the situation I appear to be in where there are 3 subscriptions (that SSMS will not let me look at because 'they do not exist').
You might have some orphaned metadata in the distribution database. If you're no longer publishing any data you might want to try Disabling Publishing and Distribution to remove the orphaned publications and subscriptions.
I find it odd that sp_removedbreplication didn't work... maybe try sp_dropsubscription, and include the ignore_distributor parameter:
declare #yourServer sysname
set #yourServer = ##servername
exec sp_dropsubscription
#publication='UD-ForCMS',
#article='all',
#subscriber=#yourServer,
#destination_db='CMS',
#ignore_distributor=1
I've found sometimes that the system view objects created by the replication can be left hanging. Stopping replication from being manually rebuilt. My solution was to manual drop the system view syncobj. I recommend always dropping the subscriptions and the publication before dropping publication properties above since I've found items get left behind leaving for long term problems.
Msg 2714, Level 16, State 3: There is already an object named
'syncobj_0x3437324238353830' in the database. Msg 21745, Level 16,
State 1, Procedure sp_MSrepl_articleview, Line 272 Cannot generate a
filter view or procedure. Verify that the value specified for the
#filter_clause parameter of sp_addarticle can be added to the WHERE
clause of a SELECT statement to produce a valid query. Msg 3931, Level
16, State 1, Procedure sp_MSrepl_articleview, Line 401 The current
transaction cannot be committed and cannot be rolled back to a
savepoint. Roll back the entire transaction. Warning: The distribution
agent job has been implicitly created and will run under the SQL
Server Agent Service Account.
I'm troubleshooting a nasty stored procedure and noticed that after running it, and I have closed my session, lots of temp tables are still left in tempdb. They have names like the following:
#000E262B
#002334C4
#004E1D4D
#00583EEE
#00783A7F
#00832777
#00CD403A
#00E24ED3
#00F75D6C
If I run this code:
if object_id('tempdb..#000E262B') is null
print 'Does NOT exist!'
I get:
Does NOT exist!
If I do:
use tempdb
go
drop TABLE #000E262B
I get an error:
Msg 3701, Level 11, State 5, Line 1
Cannot drop the table '#000E262B', because it does not exist or you do not have permission.
I am connected to SQL Server as sysadmin. Using SP3 64-bit. I currently have over 1100 of these tables in tempdb, and I can't get rid of them. There are no other users on the database server.
Stopping and starting SQL Server is not an option in my case.
Thanks!
http://www.sqlservercentral.com/Forums/Topic456599-149-1.aspx
If temp tables or table variables are frequently used then, instead of dropping them, SQL just 'truncates' them, leaving the definition. It saves the effort of recreating the table next time it's needed.
Tables created with the # prefix are only available to the current connection. Therefore any new connection you create will not be able to see them and therefore not be able to drop them.
How can you tell that they still exist? What command are you running to find this out?
Is the connection that created them closed properly? If not then this may be why they still exist.
I have a SQL Server 2005 database that could only be restored using
Restore Database The_DB_Name
From Disk = 'C:\etc\etc'
With Continue_After_Error
I am told the source database was fine. The restore reports
Warning: A column nullability
inconsistency was detected in the
metadata of index
"IDX_Comp_CompanyId" (index_id = 2)
on object ID nnnnn in database
"The_DB_Name". The index may be
corrupt. Run DBCC CHECKTABLE to verify
consistency.
DBCC CHECKTABLE (Company)
gives
Msg 8967, Level 16, State 216, Line 1
An internal error occurred in DBCC
that prevented further processing.
Contact Customer Support Services.
Msg 8921, Level 16, State 1, Line 1
Check terminated. A failure was
detected while collecting facts.
Possibly tempdb out of space or a
system table is inconsistent. Check
previous errors.
Alter Index IDX_Comp_CompanyId On dbo.Company
Rebuild
gives me
Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical
consistency-based I/O error: incorrect
pageid (expected 1:77467; actual
45:2097184). It occurred during a read
of page (1:77467) in database ID 20 at
offset 0x00000025d36000 in file
'C:\etc\etc.mdf'. Additional messages
in the SQL Server error log or system
event log may provide more detail.
This is a severe error condition that
threatens database integrity and must
be corrected immediately. Complete a
full database consistency check (DBCC
CHECKDB). This error can be caused by
many factors; for more information,
see SQL Server Books Online.
How much trouble am I in?
A corruption in an index is not nearly as bad as a corruption in the base table as an index can be rebuilt.
Compare the table and index definitions between the source and destination databases.
Check the version of both servers as well. (was the backup automatically upgraded when restored to your server)
Drop and recreate the index and rerun the CheckTable.