I can't see all of the rows in the linked-server's tables. So if I run select count(*) from cmrez.dbo.reservations on the target server itself it returns 809472, but if I run the same query from a remote (linked) server I only get 78324. What's up with that!?
I seem to have come up with a solution. The target server supports mixed-mode logins, so I created a new login and I specify for the linked server to use that login and it appears to work. I don't know why I couldn't use pass-through security, but that doesn't matter as long as it works ;-).
Related
I am a new database intern working with a access front end and SQL server backend database. The database was custom made for the company. One of my assignments is to take scripts and apply them to make four new tables. I am aware that I need to make a new query for each new table but I don't know if I should make the query in SQL server management studio or the frontend access program. I have tried copying and pasting the given scripts into a new query in access but I get an error message "invalid SQL statement expected 'DELETE', 'INSERT'...". I decided to try to break done the program a little bit and tested the first line
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id =OBJECT_ID(N'[dbo] .[FK_tblInstrumentInterfaceLog_tlkpInstrument]') AND parent_object_id = OBJECT_ID(N'[dbo].[tblInstrumentInterfaceLog]'))
but the same error message keeps popping up. I even tried just SELECT * FROM sys.foreign_keys, and I got the error message "could not find file...". I am very much a beginner and any guidance would be appreciated.Basically am I supposed to be applying these scripts the server SQL database or on the front end access program?
Are you using a pass-through query? i.e. not just a select query. Access needs to know where to send the query and since you are using TSQL not Access SQL this needs to be executed on the server.
Normally when you query a linked table the information of how to get the data (the connection string) is tied to the table. But for this kind of query you'll probably need to tell Access explicitly. Unless you are using an ADP/ADE, then the connection info travels with the program not the table.
As a general rule, you use SQL management studio (SSMS) to create and run those scripts. So the general accepted approach here is such scripts will not be placed in the front end. As noted such scripts if for some reason must be placed in the front end, then you have to create them as pass-though, but EVEN in this case you want to use the SSMS to create such quires.
So the answer here is you create the new scripts and make table queries in the back end, or in this case using the SQL server management studio.
The syntax checking, query editor etc. in recent versions of SSMS now has auto-complete etc. and you can test/write/update those scripts in SQL server. Once you have such a query or even several of them, then the resulting “several” statements can be pasted into a front end query that been created as pass-though. If you do not use a pass-though query, then you are creating and using and assuming client side SQL (JET (now called ACE)).
The client side has it own version of SQL syntax, and it is NOT 100% compatible with the SERVER SIDE. If you writing SQL in the client that is NOT pass though, then you using a linked table to SQL server. These linked tables thus will use local (JET/ACE) based SQL queries. The ODBC driver thus translates this SQL into server side compatible syntax. However the JET/ACE sql syntax is very limited when compared to SQL server and no server side commands exist in this SQL syntax for the client data engine (JET/ACE)
So for many quires, you will and can simply build such queries using the Access query builder.
However for SQL that needs to run 100% server side then such quires has to be setup as pass-though and are in most cased built + tested using SSMS.
We have 2 servers - one production, one test/development. I wanted to run some SQL checks and updates against production data but write the changes to test/development server, so people wouldn't see the changes.
Using SQL Server Management studio, I ran the cursor with the checks and updates in it. I was actively connected to test/development. However, I wrote my queries as follows.
SELECT * FROM [Production_Server].[Production_DB].[schema].[table]
I was under the impression this would look at the production server, however, it did not. It looks at the test/development server. I have access/rights in both environments.
Is there something I overlooked permission wise to get this to work? Or is just how it is intended to work?
"[Production_Server]" must be the wrong linked server name.
Run the below sproc to find the correct value to use
exec sp_linkedservers
I have a little problem. I want to create a query in my local database (tijdsregistratie.mdf) to retrieve rows from my server database (IT Solutions Develop.dbo) on server itshou-dev03\sql2008.
But I don't know how to connect to the server database. I tried it like this :
select TOP 10 * from [IT Solutions Develop].dbo.[IT Solutions BVBA$Planning]
.. but it gives me this error :
Invalid object name 'IT Solutions Develop.dbo.IT Solutions
BVBA$Planning'.
One way is to link the servers:
http://msdn.microsoft.com/en-us/library/ms188279.aspx?ppud=4
You can also define linked servers by using SQL Server Management
Studio. In the Object Explorer, right-click Server Objects, select
New, and select Linked Server. You can delete a linked server
definition by right-clicking the linked server name and selecting
Delete.
This is the process by which you tell SQL Server where another server is and how to connect to it. You can do this in SQL Server Management Studio or in T-SQL. You can then refer to the linked server by a four part name (similar to what is in your question):
[LinkedServerName].[Database].[Schema].[Object]
I have a linked server where I can clearly see all the databases and tables, so I know the server is properly linked. However, when I try to execute a query, it says invalid object name, at the linked server's table.
The linked server is aliased as TCS, therefore, my query takes that table as
FROM [TCS].dbo.table as b
I have also tried including the database name also as FROM [TCS\db1].dbo.table.
What am I missing here?
Try including the DB name like so:
FROM [TCS].db1.dbo.table as b
I don't think you can specify the DB using a slash.
I would also check to make sure your security settings for the linked server are allowing your account to connect. This article touches on how to do that.
either:
the user (used for the link) doesn't have access to the table; Grant access;
the default DB on the server doesn't have the table. You have to change it to the relevant one or included in the db in the name: [TCS].DATABASE.dbo.table as b;
When running a SQL statement or a stored procedure on a database, can you connect to an external database and pull data from there?
something like:
SELECT a.UserID, b.DataIWantToGet
FROM mydb.Users as a, externaldb.Data as b
You'll need to setup a Linked Server instance. Then you can reference the external database as though it were a SQL Server database.
Yep -- there's two methods: either use the function OPENROWSET, or use linked servers. OPENROWSET is useful for ad-hoc single statements, but if you're going to be doing this regularly, read up on linked servers as they allow you to do exactly what you've specified in your SQL Statement ... e.g.,
SELECT database.owner.table for local data
SELECT server.database.owner.table for remote data
And yes, you can mix and match to do joins twixt local and remote. Note though that you'll need to be caureul if you do joins against large tables that exist on the remote server as the query could take a long time to exexute...
Yes, you can. You should take a look at linked servers for starters. You can also use OPENROWSET to hit them directly with no linked server.
Easiest way :
Click connect to server
when it asks for server name use:
192.168.X.X,1433\SQLEXPRESS insted of YOURPC\SQLEXPRESS
(The ip and opened port of target sql server)
Type correct username and password
Done!