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.
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.
How do you access another database from same server? Got server name using SELECT ##SERVERNAME, and then did servername.dbo.mydatabasename.mytablename but query analyzer says Invalid object name. Any ideas? Am doing
insert into Myservername.Mydatabasename.Mytablename
(Email,Username1)
Values
('h','h')
Using MS SQL Server 2008, on same server
Assuming you're using MS SQL Server, fully qualified references are in the form:
[servername].[databasename].[schema].[object]
On the same server you do not need the [servername] reference.
In your case, you reversed the databasename and schema. It should be:
servername.mydatabasename.dbo.mytablename
Your INSERT should look like:
insert into Mydatabasename.Schema.Mytablename
(Email,Username1)
Values ('h','h')
(probably your Schema here is dbo)
You would include the [servername] component when performing an operation across a linked server in which case [servername] would be the name of the linked server, which incidentally may not actually be the the same as the hostname/instance name of the remote server.
Is it not rather mydatabasename.DBO.mytablename ? And if your database is on the same server, you normally don't have to use the servername.
Should be
insert into Myservername.Mydatabasename.MySchema.Mytablename
(Email,Username1)
Values
('h','h')
Though as you're on the same server you don't need Myservername. In your example which was using three part notation it would have assumed that Mydatabasename was the schema; hence the error
How can I select data in the same query from two different databases that are on two different servers, one DB2 Server and the other a SQL Server?
On your sql server, set up a linked server to the db2 database.
Then write your query on sql server. I suggest that you use openquery for the db2 stuff. If you have to combine the data, populate a sql server temp table with the openquery results and work from there.
The reason I suggest this is performance. I have found that if you use this syntax
select somefields
from server.database.owner.table
where whatever
sql server will bring back the entire table from the linked server and apply the where clause afterwards.
You can set up a linked server http://support.microsoft.com/kb/222937
How to create a linked server
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 have written SQL statements (stored in a text document) that load data into a SQL Server database. These statements need to be repeated daily. Some of the statements use the NewId() function to populate a keyed field in the database, and this works fine.
While I'm in the process of writing an application to replicate these statements, I want to use Access queries and macros instead of copying and pasting queries into SQL Server, thus saving me time on a daily basis. All is working fine but I can't find any function that will replace the SQL Server NewId() function. Does one exist or is there a work around?
I'm using SQL Server 2005 and Access 2007.
On top of matt's answer, you could simply use a pass-through query and just use your existing, working queries from MS Access.
A solution would be to insert the stguidgen() function in your code, as you can find it here: http://trigeminal.fmsinc.com/code/guids.bas https://web.archive.org/web/20190129105748/http://trigeminal.fmsinc.com/code/guids.bas
The only workaround I can think of would be to define the column in your access database of type "Replication ID" and make it an autonumber field. That will automatically generate a unique GUID for each row and you won't need to use newid() at all. In SQL server, you would just make the default value for the column "newid()".
Again, there seems to be confusion here.
If I'm understanding correctly:
You have an Access front end.
You have a SQL Server 2005 back end.
What you need is the ability to generate the GUID in the SQL Server table. So, answers taht suggest adding an AutoNumber field of type ReplicationID in Access aren't going to help, as the table isn't a Jet table, but a SQL Server table.
The SQL can certainly be executed as a passthrough query, which will hand off everything to the SQL Server for processing, but I wonder why there isn't a default value for this field in SQL Server? Can SQL Server 2005 tables not have NewId() as the default value? Or is there some other method for having a field populate with a new GUID? I seem to recall something about using GUIDs and marking them "not for replication" (I don't have access to a SQL Server right at the moment to look this up).
Seems to me it's better to let the database engine do this kind of thing, rather than executing a function in your SQL to do it, but perhaps someone can enlighten me on why I'm wrong on that.