I have two SQL Server databases that are being used for my application.
The issue is that now we have decided to move one of the databases to another new server due to performance issues.
What's the best method to ensure all the joins in the SQL queries will work correctly? Do I need to update each join between the databases to so it can reference the database on the new server?
I have already updated web.config with the change but this wont affect the joins in the queries
Any advice would be great
Thanks
For this you will need to configure the second server as a linked server: http://msdn.microsoft.com/en-GB/library/ms188279.aspx
Queries on the first server can then be updated to access tables on the second.
Be aware though, any queries that join tables across the two servers will usually be very slow - more so if the tables have large numbers of rows.
Related
First, I apologize if this has been asked or is a trivial question.
But, is it possible to connect to two external SQL databases through Microsoft Access?
By way of background one is our CRM and one is our email management system. The two are completely distinct databases. And, reside in different physical and virtual servers.
Our objective is to be able to gain insight into our email marketing efforts as it relates to client activities captured in our CRM.
We currently use an ODBC connection to read data from our CRM database.
Really, we need more information, but basically yes it is possible. All you need to do is link to the tables in the SQL databases, then run the query on the linked tables with a JOIN.
This page will tell you how to link to an SQL table: http://office.microsoft.com/en-au/access-help/import-or-link-to-sql-server-data-HA010200494.aspx
It is possible to do this in MS Access (as already said in Makita's answer).
But you won't get the maximum performance this way, because there's a certain overhead caused by MS Access on your machine (which is relatively slow compared to the DB servers and probably has a slower network connection than the DB servers), pulling data from two different DB servers over the network.
Since you tagged your question with sql-server, there's another possible solution using a feature of SQL Server: linked servers.
You can create a linked server in SQL Server A, that links to SQL Server B.
(see the above link for more information about how to do this)
Then, you can query tables on SQL Server B from SQL Server A (and even join tables from both servers) with the following syntax:
-- execute this on Server A
use DatabaseA
select *
from TableA a
inner join ServerB.DatabaseB.dbo.TableB b on a.ID = b.ID
(this code assumes that TableA is a table in DatabaseA, which is on ServerA, and so on)
This will be way faster than linking the tables in MS Access (the more data you need to pull, the faster it will be) because you're using the superior CPU power and network connection of the database servers.
Is it possible to build a generic query that verifies and if needed corrects a whole table schema?
Example:
On my dev machine i have a sql server with some tables. I, and others, make changes to the tables and sometimes misses to notify the others about them. :/
I want to build a query that reads the dev sql tables and creates a query that i can run one another sql server and updates that table there so that they are equal.
I cant drop the table and recreate it unfortunately. I dont want to change any of the data.
If this is to hard with sql syntax is there some tools that can do this for me? The sql tables are almost always on different machines and most likely i cant connect directly to them from the same place. So tha fixing/verifying needs to be done "offline".
Time is not of the essence, it can be a very slow query as long as it works.
update: I want to verify the sql schema and not the content of the table
update2: We are using SQL Server 2008 R2
It is possible, but not easy. This kind of tool is called a Data Dictionary, and you can write one yourself (see advice from the Database Programmer) or you can buy a commercial one, for example RedGate's SQL Compare.
I am not sure what the best design pattern for this problem is so any suggestions would be greatly appreciated. I have two SQL Servers A (with DBs P,Q,R) and B (with DBs X,Y,Z).
What is an efficient way to do a join of tables situated on Server A with those on Server B from command-line? Basically, I am trying to automate a long running list of queries and am not really sure how to proceed.
EDIT: I do not have control over the servers and am not an admin.
At a minimum I would create a Link Server between the two servers. Using something like OPENROWSET will be slower than using a Link Server.
Depending on how fast you need these queries to run you might consider having a nightly process that copies the data from Server A to Server b (or the other way around) so that you don't need to worry about cross server.
There is no way of performing a join across different servers. You can either use a cluster solution on top of those servers to do it for you, or you can do it by yourself - reading from one table, and performing the join manually in your code.
I have a database server that currently has two databases, call them [A] and [B].
[A] is the standard database used for my application
[B] is used by another application (that puts considerable load on the server), however, we use a few tables sparingly (that are shared between my application and the primary application that utilizes [B]). Recently the use of [B] has been increasing and it's causing long wait periods and timeouts in my application.
I'm open to alternative ideas, but at the moment the quickest potential solution I've come up with is to get a second database server and move [A] to that. However, I do need access to some of the tables in [B] - ideally with as little code changes as possible.
We were thinking a setup something like:
Current:
DB Server 1 {[A],[B]} (SQL Server 2005)
New Setup
DB Server 1 {[B]} (SQL Server 2005)
DB Server 2 {[A], [B]} (SQL Server 2008)
Where in the new setup, DBServer2.[B] is a linked table (kind of) to DBServer1.[B]
I looked into linked databases, from my understanding (limited) those work as an alias to a database on another server, which is almost what we want, except it adds the extra server qualifier, and it works on the db level. I'd like to do something like this, but ideally without the server qualifier and on a table level.
So for example, [B] has tables Users and Events. The Users table is updated weekly by batch, and we use it often, so we'd like to have a local copy on the new DBServer2. However, Events we use far less often and needs to be real-time between the two servers. In this case, it would be great to have Events as a linked table.
Further, it would be fantastic if we could use the same markup for queries. Today to query one db from the other we'd do something like
select * from b.events join a.dates
We'd like to continue that, except have the database server know that when we touch events it's really located at dbserver1.b.events.
Does that make sense? I confuse myself sometimes.
Thanks for any help
~P
You can use synonyms for linked objects - http://msdn.microsoft.com/en-us/library/ms177544%28SQL.90%29.aspx
This unfortunately only works for single objects, you CANNOT make a synonym for linkedserver.databasename and then reference synDBName.table.
"Alternative Idea" from me since you said you are open...
How about looking into the cause of the slowness? What is the "Load" you are measuring?
How are your disks laid out on the server?
Maybe you could use more memory, another CPU or Some SQL tuning?
Fixing your issues with a software or hardware fix MAY be faster than getting a server and doing all the installs and then working through the integration problems you may run into.
I've recently been upgraded to Office 2007. I have several Access databases (that I've kept in the Access 2000 format for several reasons) that are linked to SQL Server 2000 databases. I have dozens of queries in these databases that I use often. I create new queries daily, sorting, summarizing and generally analyzing the data.
Since the upgrade, some queries take an extremely long time to complete (minutes rather than seconds), and one new one I've tried to run doesn't complete at all, I have to end task on Access. It's a rather simple query, it joins 3 tables, and sorts on one of the fields. I do this ALL THE TIME, and now it appears I can't.
I've searched for discussions of similar problems, but haven't seen specific recommendations.
Any ideas?
I would suggest deleting all your ODBC linked tables and recreating them from scratch as a starting point.
If your queries do not need to make any changes to the data you may find converting them to SQL Pass through queries will speed them up considerable. Note these queries are not parsed through the Jet DB Engine but sent directly to the server and bypass any linked tables.
You will have to use MS SQL syntax and lose the QBE grid though and the result will be read only.
If you need to update data then maybe stored procedures are the way to go.
When I converted to SQL Server backend, I used SQL Server Migration Assistant. I recommend it highly. It's very good at what it does.
Having said that, I assume you're using linked tables in your FE. I convert slow-moving queries by copying the SQL from Access, then pasting it into a "new query" window on SQL Server Management Studio. Then, working through all the syntax changes one at a time, I convert the query to T-SQL and save it as a view with the same name as the query in Access.
I have a little routine that then renames the Access query to "Local_" and then creates a linked table entry to the view on SQL Server. You'll find that a query that used to run for minutes will run for seconds this way. You can, of course, do this manually.
SQL Server Migration Assistant, by the way, will convert many queries (it doesn't try to convert action queries, only select queries...) with little or no intervention.
I would use Access Data Projects with SQL Server 2000. It works great when your SQL backend is that old.