I have a doubt about how to properly use JOIN SQL queries.
Imagine that I have 3 tables. I want to make a RIGHT JOIN between two of them. This is, I want to show all the records from the left table and just those records from the right table where the join is equal. Once I have this, I want to make another JOIN (inner or whatever) between the table that was on the right (now is the LEFT table) and the third table (that is the RIGHT table). So that, I would have 3 tables connected. My problem is that I get a message error from access that is:
The SQL statement could not be executed because it contains ambiguous
outer joins. To force one of the joins to be performed first, create a
separate query that performs the first join and then include that
query in your SQL statement.
So, Access is forcing me to use two separates queries but I don't want to use two. I think that this must be possible in just one. Am I right? Do you know if there is a method for this?
Thank you all.
Can you try this ?
Put the inner join first
Source : Source
Related
Is it possible to select multiple options inside this box?
No you can't, nor does it make sense to. When writing a query you need to be specific on what you want, and how you want that data to relate
Take the image in your question, where you are selecting a table name, if you select 2 tables, how is that meant to appear in the query? To have 2 tables in the query you need a JOIN. What type of JOIN should that be? An INNER JOIN? a LEFT or RIGHT OUTER JOIN? Perhaps a FULL OUTER JOIN or even a CROSS JOIN? If any but the last, what is the ON clause for said JOIN?
What about if it were a function? Would the other functions be called with a CROSS APPLY or an OUTER APPLY? What are the values of the parameters?
Intellisense doesn't know what you want, only you know that. It's prompting potential options to you, in this case objects that match the name of what you've typed already, but it doesn't know what you're going to do with those objects afterwards. It's not able to predict your intentions; it's just listing objects names that match your existing text.
Intellisense is there to assist you write the queries but it's not there to literally write them for you; that's for you to do.
I'm writing a report that needs to pull data from a view that I'm not authorized to modify. The view is missing a column that I need for a report, so I attempted to join it against one of its source tables. However, this is causing it to take twice as long to execute.
A look at the execution plan shows that it performs two scans of the table and merge joins them together. Is there a hint I can use to convince the query optimizer to visit the table only once?
Abstracted fiddle: http://sqlfiddle.com/#!3/4a44d/1/0
Because the optimizer will never eliminate a table access specified in the query unless nothing is actually referenced from that table.
There is no way to access a table less times than it is referenced in the query (as far as I know from 13 years experience). There may be a few other cases, but the only case I know of where the query optimizer can do less accesses than the number of object references is when it can optimize away a left outer or right outer join when nothing is accessed from the outer table and it is known from constraints that excluding the work will not change the number of rows or which rows would be returned in the result.
My professor stated that certain queries need to use a view, instead of a join because a join will calculate values multiple times - producing an incorrect result. Why does this happen? And how does a view protect from that?
If you're using a view in place of a join then your view probably contains a join. A view is simply a stored query. It presents to you a virtual single table but may be made up of joins across many tables, or it may contain aggregated data.
Based on that, I'm assuming there is more to your professors logic because your statement doesn't make sense.
Any ideas how I can create a join on a table retrieved from data in a previously joined table? For example, I have an objects table that contains existing table Names, the display field of those tables, and the main ID field of those tables. I want to join on the table specified in the objects table as well as the objects table.
select T.field1,T.field2,T.field3,O.DisplayName
from tableT as T
inner join objects as O on T.SystemObjectID = O.SystemObjectID
inner join O.TableName as X on X.O.ID = T.SystemObjectRecordID
I understand the script above is not correct. But what is the easiest most efficient way of accomplishing this task? I hope I'm clear on what I'm asking...
Thank you for any help in advance.
You can't do that.
What you can do is take the results of that and create a string that is a SQL query.
You can even make that query parameterised and execute it using sp_executesql.
- That link has a few good examples to get you started.
This is because SQL is compiled to an execution plan before it is executed. At this point in time it needs to know the tables, decides the indexes to use, etc.
This means that data is data and sql is sql. You can't use late binding scripting tricks to modify the query that is already running.
You're stuck with SQL that writes SQL (Dynamic SQL) I'm afraid.
I have a Data Flow Task that does some script component tasks, sorts, then does a Merge Join. I'd like to have the Merge Join do the join as a 1-many. If I do an Inner Join, I get too few records:
If I do a Left Outer Join, I get WAY too many records:
I'm looking for the Goldilocks version of 'Just Right' (which would be 39240 records).
You can add a Conditional Split after your left join version of the Merge Join, with a non-matching condition like
isnull(tmpAddressColumn)
and send the relevant matching flow condition (the default output) to your destination.
If you still don't get the correct number, you'll need to check the merge join conditions and check if there are duplicate IDs in each source.
The number of rows shouldn't be what you're using to gauge if you're using the correct options for the Merge Join. The resulting data set should be the driving factor. Do the results look correct in the tmpManAddress table?
For development you might want to push the output of the script components to tables so you can see what data you're starting with. This will allow you to work out which type of join, and on which columns, give you the results you want.