I am using ColdFusion 9.1.
I need to use two different datasources in some of my queries. I know it can be done because I see other code that uses two different datasources and it works fine.
I've tried lots of combinations but can't get anything to work, but I know that both of my datasources are working properly.
I have a default database set up in the THIS scope. The default is "DatasourceOne".
<cfquery>
SELECT UserID
FROM DatasourceOne.TableOne IN (SELECT Userid FROM DatasourceTwo.TableTwo )
</cfquery
What are the rules or guidelines about using multiple datasources?
CLARIFICATION
I should have originally asked how I could use two database (not datasources) in a single query. I am sure your answers would have been different. We do have both databases set up as datasources though and I was a little confused myself.
Depending on your database, if the second database is on the same server (or is defined as a linked server) and the user in the datasource has permission, you can usually reference the other database.
SELECT * FROM myTable
WHERE myField IN
(SELECT otherField FROM otherDatabase.dbo.tableName)
You can't talk to two CF (JDBC) datasources in a single CFQUERY. What you can do:
Use two databases on the same datasource. For example, if you have a SQL Server instance with two database you can run a query through the JDBC connection that talks to both databases. This looks like what you're describing in your question. Here's a more thorough explanation.
Use Queries of Queries. Pull your data from the two database individually and join the results using a QoQ in your CFC or page.
ColdFusion can only talk to one data*source* at a time in a given query. However, if you need to talk to more than one data*base* on the same server, you can do that by explicitly giving the full paths to the databases, tables, and columns you need to access or join together. Also note that the user that the data*source* in ColdFusion is configured to use must have access to both databases in order for this to work.
Related
Is that possible? I'm using Aquadesk and I can't get it to work. The tables have a matching unique identifier and wondering if I can match them up in some way.
What you need - as I think - are "Federated Servers" (Databases) (you can look this up)
The basic idea behind that is, the you can create (catalog) a table in you local Database that is already residing on an other Database (or Server, or even an other DB System, but that depends in you SQL system and version) -> that is defintely a question for your DBAS
You get a table like 'MYSQL'.'PERSONS' that resides remotely (eg. 'BASE','PERSDATA'), so you can use them in a
`SELECT *
from 'LOCALNAME'.'USERS usr
JOIN 'MYSQL'.'PERSONS' pers
on usr.user_id=pers.id`
So jou can select and join over different Databases (and Servers)
I only used that whith IBM/UDB but it works realy fine, and has a fair performance (altough heavily depending on your statement)
I am developing a web application (using classic asp for now) that needs to query two tables on two separate databases on the same server.
I have been given separate application-level login/passwords for each database by the IT team which will be used in my code to connect.
I want to create a query that links two tables (one from each database) together, but not too sure how, and Google hasn't helped me much either.
I'm assuming I have to create two connections to do this as I have two separate logins, but how then would I create a query that uses tables from each.
Just a note - our IT team will not at this stage link the two databases together. I'm pretty much stuck with what I have.
Hope you can help.
Mat
If the IT team wants the databases to be separate, you obviously can't use the database to do the join for you.
You'd have to execute the join client side. Linq is an easy way to do that, but a loop with two datasets also works.
The typical syntax for a cross database query would be something like:
SELECT <columns>
FROM [schema].[table] t1 INNER JOIN
[databaseName].[schema].[table] t2 ON <condition>
However, if you're using 2005 or above, it's well worth creating a synonym in the first database so that the reference to the second database isn't peppered throughout your code (what if the database name changes later)?
CREATE SYNONYM [schema].[synonymName] FOR [databaseName].[schema].[table]
Then your query becomes:
SELECT <columns>
FROM [schema].[table] t1 INNER JOIN
[schema].[synonymName] t2 ON <condition>
You may need to set permissions appropriately such that the user you are using to connect to the first database has access to the second. If the IT team simply grants the relevant access to both databases from the same server principal, that is the best way to achieve it. If you are stuck with having two totally separate logins then that sucks. But there isn't any need to 'link the databases together' in order to run a cross-database query.
The company I work for uses a bunch of different SQL servers and I was wondering how to select a different SQL server in the same script.
For example, I want to select data from a table on a database in server 1 and using that data to get data from another table on a database in server 2. I tried googling the solution but I couldn't find anything relevant to my problem.
Thanks in advance.
You can set them up as linked servers.
http://msdn.microsoft.com/en-us/library/aa560998(v=bts.10).aspx
then you syntax will be
SERVERALIAS.DBNAME.owner.TABLE
Use fully qualified names (i.e. select * from [server].[database].[owner].[tablename])
Also, be sure to setup those servers as linked servers. There are several articles online how to do this.
I agree with Kyle & Flavio that You have to use four part naming convention to whatever server,database,table & column data like this:
Select * from [Servername].[Databasename].[Owner].[Tablename]
A cleaner option is to set up Synonyms to your linked servers. This way, you alias the server, and therefore don't have to hard code the 4 parts into every query.
If you hard code and later change a server's name, you will have to hunt down every reference and update. With Synonyms, all you'll have to do is update the applicable Synonym.
Synonyms give you transparent external tables, procedures, and UDFs.
MSDN here.
I need to do the following query (for example):
SELECT c1.CustomerName FROM Customer as c1
INNER JOIN [ExternalServer].[Database].[dbo].[Customer] as c2
ON c2.RefId = c1.RefId
For some security reason my client doesn't allow me to create a linked server. The user under whom I execute this query has access to both tables. Is it possible to make it work without using linked server? Thanks.
You could use OPENROWSET, which'll require the connection info, username & password...
While I understand that the client believes that having an always-on connection to their data is risky, that's why you lock down the account. OPENROWSET means including the connection info in plain text.
'Linked Server' is a very specific thing -- basically, a permanent connection between servers. I can think of all sorts of reasons not to want that, while at the same time having no problem with folks writing queries that combine data from the two different data sources.
Anyway, depending on your requirement -- if this is just for ad hoc querying, OPENROWSET is good if inside of SQL-Server, or if you want to do this in MS Access, just link to the two tables, and your Access query won't care that one comes from one server, and one comes from another.
Alternatively, with a web or windows front-end, you could indpendently query each table into a data object, and then build a separate query on top of that.
Http Endpoints...
WebServices...
There's a million ways. I wouldn't be so quick to assume, as #Lasse suggests, that any form of 'linking' this data together would make you some kind of rougue data linker.
I have to develop database development standards for our organisation for SQL Server and any code that interfaces to it. The code used can be anything from .NET code to VBScript to SQL Server Jobs.
Does anyone have a good link for this kind of thing?
My quick list is follows:
1) Naming Conventions
-- Stored Procedures usp_AppName_SPName
-- Functions usf_AppName_SPName
-- Indexes IX_TableName_IndexName
-- Tables AppName_TableName
-- Views VW_Name
2) Allocation of permissions to roles, never directly to users or groups
3) Allocation of roles to groups, never directly to users
4) Use of minimal permissions
5) No inline sql in code, always use SP or Functions
6) Use of explicit transactions
7) Readonly transactions where applicable
8) Always use explain plans to ensure sql is performant.
What other things do we need to cover? I am sure that there are lots of things....
Since we are talking best-practices I'd throw in a few things to avoid:
avoid use of xp_cmdshell
avoid dynamic sql unless strictly
necessary (such as for dynamic pivoting)
avoid cursors (if not on temp
tables)
P.S. Btw - I am doing all of the above ;)
I found the following quite useful:
http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterSQLServerDatabases.aspx
http://www.codeproject.com/KB/database/sqldodont.aspx
Also consider using multiple schemas. Use AppName.TableName instead of AppName_TableName, where AppName is a schema. The AdventureWorks sample does this, for instance.
I have to take issue with your first item right off the bat. While I know a lot of people like to use prefixes for stored procedures, tables, and the like, I've never had much use for that convention. When you start to get a lot of stored procedures that all start with "usp_", and you click to the expand the "Programmability\Stored Procedures" folder in Management Studio, it can be rather unwieldly to navigate.
Instead, require a prefix to match the logical feature set/functional group. What those prefixes are will vary by application or database. Then if you want to distinguish a stored procedure from a table, add your "_usp" requirement as a suffix.
For tables: you want something in your naming convention to distinguish between Application data (lookup tables) and User data.
Aren't roles and groups the same thing in SQL Server?
A few others...
Avoid using UDFs in WHERE clauses
Disallow direct SQL in applications
(always use SPs)
Use comment blocks in front of
views/procs/functions including a
revision history and/or revision
date
Use ANSI join syntax
Limit use of triggers, especially
for replicated tables