SQL Server error - Operand type clash: ntext is incompatible with int - (I'm not even using "ntext") - sql-server

One of the columns I'm operating on is:
Comments VARCHAR(8000)
So basically I'm trying to insert a large text of up to even 600 characters into this column Comments. When I run my script everything goes smoothly for first 10 rows then all of a sudden I get this error:
pypyodbc.DataError: ('22018', '[22018] [Microsoft][ODBC SQL Server
Driver][SQL Server]Operand type clash: ntext is incompatible with
int')
Then again if I rerun the query, everything will start going smoothly for next 10 rows and as you might have guessed by now I get the same error again.
What can I do to fix this?
Edit:
I have tried using VARCHAR(MAX), NVARCHAR(MAX), VARCHAR(800), TEXT. I get the same error every time.

I wonder whether it is a problem with the data on row 10?
To test this, try deleting the data on, say, row 5, and see whether the error starts on row 9.

I would recommend you using pmyssql instead of pypyodbc. Seems like it is a driver level issue and switching to pymssql might help. Please follow the ACOM doc and let me know if that helps. If you still run into the same issue let me know as I can further try to help you.

Related

rsProcessingError - Reporting Services Error - rsErrorReadingNextDataRow

I have ran into a strange issue in one of my SSRS reports. I get the following error:
"An error has occurred during report processing. (rsProcessingAborted)
cannot read the next data row for the dataset Defect_Summary. (rsErrorReadingNextDataRow)"
Whenever I run this dataset's query in query designer, or in management studio, the query runs fine. However, when I run the report in report builder or on the server I get the above error. After researching I have found that the issue has something to do with my parameter.
I have a parameter #PO (Production Order) where the user will provide an 8 digit number i.e. 11002575. In my query I have the following line: OrderNr / 10000 = #PO. In the database, OrderNr is of type bigint and will have a value such as 110025750020. I divide this number by 10000 so that the 8 digit #PO parameter equals the OrderNr such as 11002575.00 = 11002575. I used to use LEFT(OrderNr, 8), but found it slowed down the query so this division has worked better for me.
Anyway, here's the strange part: When I first encountered this error, and after researching, I changed my parameter to type integer (from text). This fixed the problem temporarily and the report ran fine. Then I encountered it again, so I changed the type back to text, and again, it fixed the problem temporarily and the report ran fine. I keep going back and forth with this temporary fix and have not been able to find a permanent resolution to this error, it just keeps coming back after a while of working and then all I know to do is keep going back and forth from integer to text. Can anyone help me resolve this error permanently?

22003 8115 error with overflow bigint id

My code runs fine in a single test. The id starts with 1 and increments by 1. However when I test the whole run in django, I've got this error.
For example, an id 601193234094856941 was inserted. In the whole run I have not more than 10000 inserts. This problem occurs in our development environment.
We have a work-around but we want to understand how it works and find a solution.
('22003', '[22003] [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]Arithmetic overflow error converting expression to data type int. (8115) (SQLExecDirectW)')",
All variables are bigint. The id above has been correctly inserted in the database but apparently the id reached a value above the max of a bigint with later inserts.
Based on the information you've provided this seems to be what would be expected. the reference id 601193234094856941 exceeds the value for an INT type. The code below throws an error of "Arithmetic overflow error converting expression to data type int.". Do you have additional information to provide that might help address your issue?
DECLARE #big BIGINT = 601193234094856941
, #regular INT;
SET #regular = #big;

sum(DATALENGTH) returning an "Arithmetic overflow" error

I am new to SQL Server so please accept my apologies if my question seems too easy. I tried finding a solution, but so far I couldn't see anything that I could use in my query.
I am trying to find length of the biggest columns in a table and I'm using the following query.
SELECT
SUM(DATALENGTH([INSDetails])) as [INSDetails]
FROM
dbo.Contractors
The table Contractors is slightly over 8GB and has over 30mln rows. INSDetails column is varchar(2048)
The query above works perfectly well for all the other columns of all the other tables in my database, but when I run it on Contractors table it returns an error
Msg 8115, Level 16, State 2, Line 26
Arithmetic overflow error converting expression to data type int.
I understand that this error message appears when you try to convert a value of a certain datatype to another datatype, but that value is too large for the second datatype.
Could you please help me to rewrite the query or suggest alternative approach to get the output?
I read that someone suggested using CAST AS big int to solve this issue, but I'm not sure how it can be incorporated in my query.
Any suggestions will be appreciated. Thank you in advance.
select sum(cast(datalength([INSDetails]) as bigint))

SELECT DAY('2007-04-30T01:01:01.1234567 -07:00') does not work?

This sql statement:
SELECT DAY('2007-04-30T01:01:01.1234567 -07:00');
is copied from the SQL Server 2012 documentation and tested in my SQL Server 2012 express edition environment. But there was an error saying
Conversion failed when converting date and/or time from character string.
I understand that the character type argument passed in DAY() is unable to be converted to a datetime type value, meaning it has the wrong format (incompatible with some current settings related to SET DATEFORMAT or any settings I don't know). So that's what I would like to know about. Could you explain why that sample statement (not of mine) does not work in my environment. My SQL Server instance was installed with default settings, I've not changed anything after installing it.
By modifying the input string a little, it works:
SELECT DAY('2007-04-30T01:01:01.123'); -- Works!
But these don't (saying the same error I posted at first):
SELECT DAY('2007-04-30T01:01:01.1234'); -- just add 4
SELECT DAY('2007-04-30T01:01:01.123 -07:00'); -- just add -07:00
Looks like there is some settings related to this problem, please tell me what it might be and how to fix this issue (I don't want to change the input string as I tried to make it work).
Thanks for your time solving my problem!
UPDATE:
Also done as some suggestions, like this:
SELECT DAY('2007-04-30T01:01:01.1234567-07:00');
SELECT DAY('2007-04-30T01:01:01.123-07:00');
but it still does not work.
Well, I found the problem. In fact the statement itself (as some ones suggested) should work, but that's just one side of the problem. The other side is the compatibility level of the current datatbase. In my case it's just 90 (which is SQL Server 2005), so explicit casting is required. By changing the compatibility level to 110 (SQL Server 2012) or explicitly casting, it works expectedly.

Why is this data type conversion failing but not failing?

Ok, so I'm wracking my brain on this one...
These two queries... though they appear the same... are apparently different in some fashion. When run against a database in SQL Server Management Studio the top one results in an error (Conversion failed when converting from a character string to uniqueidentifier.) where as the bottom one runs just fine. Any ideas as to why that would be?
SELECT CONVERT(UNIQUEIDENTIFIER,'459B621C-A49A-49Cl-900F-AB14D61841E2');
SELECT CONVERT(UNIQUEIDENTIFIER,'459B621C-A49A-49C1-900F-AB14D61841E2');
Could it be a character encoding issue?
Thanks
There is a difference. The first one uses an l, the second is 1.

Resources