I have successfully created linked server between 2005 and 2008 version. We changed a table schema on 2008 and re ordered the table columns. We also did the same on 2005 server.
If we query both table in their own database then schema looks fine however
when I do
SELECT * FROM and Select * from then it is showing me old schema for 2008 table. Due to this my join and inserts are failing. Error "insert failed due to table column mismatch"
We restarted both the machines still not luck
Any idea ?
After some research I found answer on stack overflow it self :D
Column name or number of supplied values does not match table definition
Do drop #table and then select * INTO
Related
I have an SSIS package that sends data from SQL 2014 to an Oracle 11G DB. No issues connecting or transferring the data to Oracle but it fails when updating the source SQL tables. SSIS give ORA-00971:missing SET keyword
Based on the below why would Oracle be looking for a SET keyword? The update statement is on the SQL database
I've switch connections to reflect the SQL tables (errors resolving the Oracle table names then)
UPDATE INTERFACE.dbo.TURN
SET INTERFACE.dbo.TURN.DUPLICADO =
INTERFACE.dbo.TURN.DUPLICADO + 100
WHERE EXISTS
(SELECT
*
FROM [REMOTEORA]..[REMOTEORA].[TURN_BALANCE] BO
WHERE BO.[TURN_BALANCE].[ID_TURN]=INTERFACE.dbo.TURN.N_TURNO AND BO.
[ID_PLACES]
= INTERFACE.dbo.TURN.ID_LUGAR AND
BO.DT_CLOSE =INTERFACE.dbo.TURNO.FIN_TURNO)
AND (INTERFACE.dbo.TURN.DUPLICADO < 100)
First changing the connection for the updating piece to the SQL server resolved the ORA error but the updates were still failing and calling TURN_BALANCE a column. Altering the table alias to four letters (BOYO) vs the two (BO) completely resolved the issue
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.
I need to query a table from another SQL Server on a different server but same domain, but I am not sure how I will be able to do it.
I tried solution given in this answer Can I create view in my database server from another database server but it doesn't work for me as I got SQL Server 2000 (please don't hate :-) ).
When I try solution given then i get this error,
Line 23: Incorrect syntax near '-'.
which is because command is not compatible with SQL Server 2000.
Edit
SELECT * FROM AnotherServer.AnotherServerDatabase.Server.Table1
you can link the servers and run cross server queries as long as you put the server name before the DB your running the query on.
For example
SELECT * FROM "linkedserver".dbo.aTable
(without "" marks )
bear in mind different server versions though. I run cross server queries from 2008 to 2000 servers and its a pain adapting :)
This is a little strange for me. I have script like following
DECLARE #maxCustId INT
SELECT #maxCustId = MAX(CustomerId) FROM Customers
SELECT * INTO #temp FROM linkserver.DB.dbo.Customers where CustomerId > #maxCustId
-- Copy records to local db Custome table
DROP TABLE #temp
But sometimes #temp does not fetch all records from linked sever.
Like I had Max CustomerId = 1138 in my local db and when I run above script my temp table (which fetch records from linked server) misses CustoemrIds 1140, 1141. Linked server has customers upto 1160. #temp table has records upto 1160 but misses two records i.e. 1140, 1141
I run that script again and again and on 4th attempt the record 1141 added in #temp table but record 1140 was still missing.
I then put following query on local server to check record in linked server
SELECT * FROM linkserver.DB.dbo.Customers where CustomerId = 1140
Above query return no records.
To verify this I went to linked server and wrote same query on server from where I have created LINKED server.
-- This is the server which I am using as linked server in my local server
SELECT * FROM Customers where CustomerId = 1140
Custoemr 1140 was in db, which I was sure that it would be there but I run above script to verify it.
I come back to my local server and run this query
SELECT * FROM linkserver.DB.dbo.Customers where CustomerId = 1140
This time my linked server returns customer 1140 which it was not returning earlier.
I run the whole query again and now my #temp table has all records.
I am so confused that why first time linked server did not return all records.
This is sample from a long procedure which copy records from linked server to local server and because of this reason my local db has less records than linked server db.
Linked server: SQL Server 2005 Standard with SP2
Local Server: SQL Server 2008 Web Edition with SP2
Provider: SQL Native Client 10
Linked server security options:
Be made using the securing context
Remote Login
With Passowrd
login user details:
Server Roles: public and sysadmin
User Mappings: sa is not mapped with
db I query.
Linked server db updated frequently
No NOLOCK at any point in query
Any help.
I have seen similar behaviour with linked servers (although usually Oracle not SQL Server) and the problem was traced to the driver being used for the linked server.
I see you have SQL Native Client 10 as the provider, could you try using Microsoft OLE DB Provider for SQL Server instead and seeing if it makes a difference?
Also would be curious to know if you have the same problem when you use OpenQuery instead of the four-part naming convention:
SELECT * FROM OpenQuery(linkserver,'SELECT * FROM Customers where CustomerId = 1140')
IIRC, that should be faster, anyway... I believe that would force it to take care of the "where" part on the linked server and only return the appropriate values as opposed to returning the whole dataset and doing the filterin' on the destination side. Of course, I'm also pretty sure I saw a UFO at my Granny's house when I was eight, so take my wisdom with a grain of salt.
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.