I have a query that queries a linked SQL server 2008 database and joins data from a table in that database to a table in SQL server 2000. It was working find until one of the columns in the SQL server 2008 database was changed to varchar(max). I received an error and I fixed it by using CAST(varchar(max) column AS varchar(50)). Now my queries performance is slow compared to how it was before the change. Can you give me some suggestion on how to fix the issue. Thank you for your time.
As the other commenters have pointed out, why was the column changed to varchar(max) if it can be reliably cast to varchar(50)?
Varchar(max) was meant as a replacement for the text datatype and should not just be used casually. A plain varchar can support up to 8000 characters and is recognized by SQL 2000 and 2005.
If you are doing this cast() in the select list, as a join condition, or in the where clause? Distributed queries already perform slow and by adding functions (cast, left, etc) in the where clause or join conditions is only going to make it worse.
Assuming that you cannot change the varchar(max) to a plain varchar, here's an idea
Does the 2005 box have a linked server connection to the SQL 2000 box? If so, can you run the query that way. The 2005 box will be able to compare the varchar(max) to the varchar(50) directly.
Related
I am querying a sql 2000 database on a sql 2008 database (linked server) and in the linked server i have a data with accents in. However when i query the 2008 database the accents appear correctly and as expected. But when i run the query on sql 2000 database the data is not showing correctly.
SQL 2000 Collation - SQL_Latin1_General_CP1_CI_AS
SQL 2008 Collation - SQL_Latin1_General_CP850_BIN2
I have attempted to add "COLLATE" to my queries however it is just not showing the data correctly.
Any ideas?
Thank you.
It turned out the issue was that the data types for the columns were varchar when they needed to be nvarchar. By dropping the table and recreating it with the correct data type this resolved my issue.
We're migrating form SQL Server 2005 to 2014 for a pretty large environment. And we've noticed that OPENQUERY behaves differently when interacting with MySQL database when it comes to datetime. Previously, it would translate just fine to DATETIME column. With 2014 (I assume started in 2008 or so), it now converts to DATETIME2 (with maximum precision). This causes problems when comparing to or inserting into DATETIME columns.
Is there a way to specify on a server-level (or specify default) for which type those will translate to? Rewriting all of the queries will be quite an undertaking, and I'd like to avoid this now, if possible (rather rewrite as we edit or introduce new things).
Try to Use VARCHAR datatype while migration of date fields, and it is always easy to Convert/Cast in various types as per need.
Yeah, stupid question but I cant make it to max even it should be possible. It just allows me to put only 8000 to varbinary and not max. I tried this in edit table schema when i right clicked the table in server explorer.
you cant! SQL server CE doesn't support VARBINARY(MAX) the equivilant would be image but i believe they are phasing that out
This is the second time it happens to me and before modifying a 3rd party Database structure I wanted to know if anyone knew a better solution:
I'm accessing a MS SQL Server 2008 from a Lotus Notes Agent (Notes 7) to retrieve some data. I use LSXODBC and my "Select" statement works perfect... Except that my agent cannot "understand" Nvarchar SQL Field types. Any other data types work ok (can get the values from number and dates fields without a problem).
It took me a while to figure it out, and I couldn't find a solution (other than modifying the field types on the SQL table to Varchar instead of nVarchar)
I could replicate this both in MS SQL 2005 and 2008.
Last "elegant" solution was to create an SQL view -instead of modifying table structure- with the varchar types instead of nvarchar. Works ok but I have to create a view for each table I'm retrieving data from.
I tried to set the Field type using FieldExpectedDataType Method but didn't work. Still got a DB_TYPE_UNDEFINED.
I thought there might be some configuration issues? or maybe I'm using an old LN Version / ODBC Driver version?
Any hint would be greatly appreciated.
Thank you in advance.
Diego
An old ODBC driver may not support unicode. It was not added until SQL Server 2000 (I'm fairly sure)
I am attempting to create a linked server from a 2005 to 2008 Microsoft SQL Server. I do this regularly for 2005 instances, but this is the first step of my long journey into SQL 2008. I am able to create the linked server as any other linked server, I receive no errors, however any time I try to use the linked server for anything (a simple "SELECT *" statement, for example) I get this error in SSMS:
"OLE DB provider "SQLNCLI" for linked server {linked server name} returned message "Invalid character value for cast specification"."
What do I need to know about creating a linked server to a 2008 instance in a 2005 instance?
Turns out the tables I kept choosing to test, the most business important tables on the 2008 server, each had fields of the "geography" data type, which is new to 2008. When testing queries on one of the other tables without this datatype the query works correctly.
So...you know... it was...an "Invalid character value for cast specification" after all.
I suspect that this may be a collation issue.
Check that the collation is the same at the server, database and table levels.
To check the detault server collation run the following T-SQL:
exec sp_helpsort
To check the Databasea collation do the following:
SELECT DATABASEPROPERTYEX('DatabaseName', 'Collation') SQLCollation;
It's either collation (my first guess), or Unicode conversions (VARCHAR vs NVARCHAR). I'd upvote John, but I don't have enough reputation.
Was there a particular way that you were able to query the table on the linked server that had the geography fields and not get the error?
I have the same issue where I need to query a linked server and some of the tables have geography fields in them and even if I only select a text field I get the error. The only workaround that I can think of would be to split the geography fields off to new tables so that the queries to the tables don't break.