SQL Server nvarchar to Crystal Reports number overflowed an int colum

[mophead]

Tables and Views contained in a SQL Server database contains a field (Parcel_UID) defined as nvarchar(50)
This field contains a 13 digit number (e.g. 1000017299772)
I use Crystal Reports 9 to connect to the SQL Server database so that I can use the views to create a report
However, Crystal Reports converts the Parcel_UID field to a "number" data type
When I use the Crystal Reports Select Expert to filter the data on the Parcel_UID field, I get an overflow error

The statement used in the Select Expert is as follows:
{vw_DistinctParcels.Parcel_UID} > 0
Where vw_DistinctParcels is the name of the view used

When I execute the select statement the error I get is as follows:
Not Supported
Details: ADO Error Code: 0x80004005
Source: Microsoft OLE DB Provider for SQL Server
Description: THe conversion of the varchar value '1000017299772' overflowed an int column. Maximum integer value exceeded
SQL State: 22003
Native Error: 248

Any suggestions or solution would be appreciated

 

[Turkbear]

Hi,
Crystal may be doing an implicit Cast to number because you specified a number ( 0 ) instead of a Character ( '0' )
in your select statement..
Try placing the 0 in Quotes and see if it helps..







To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[mophead]

OK, I think there is one thing that is being misunderstood here. Crystal is automatically converting the nvarchar to number from the database connection. The filter I use in the select expert does not and cannot change the data type taht appears. If I use "0" instead of 0, I get an error saying "A number is required here". And vice versa, if there is a string field and I use 0, I will get an error saying "A string is required here". The problem is with Crystal Reports not recognizing a nvarchar in SQL Server as a string

 

[mophead]

Ah a break through. For some strange reason after I re-executed the views on the SQL Server end and then refreshed the database connection several times on the Crystal Reports end, only then did Crystal interpret the field as string. This doesn't make a whole lot of sense to me since we didn't change the data type on the SQL Server end...we just simply re-executed the view