Okay guys, i'm literally SCREWED. My professor is on indefinite leave and I have an assignment due next Friday which I'm completely lost on. I've entered all my data into my tables and I'm creating the views. Our assignment is to create 5 reports for a business in SQL and transfer them to Excel to create a frontend.
Basically, can someone describe to me how I would I utilise view and joins to create a report for this
A join means you are going to match up columns in two tables that have the same column, and add the data for both tables together, essentially creating one big table. You can create a view by using this code. What that will do is give you one thing to call, the view, and it will contain all of the code from the joins you did to create it, so you don't have to re-code and re-validate every time you want to use those joins. This isn't the place where we can just give you what you'd learn in your course, but I hope that helps.
Example:
select *
from tableSales a
join tableStaff b on a.Staff_ID = b.Staff_ID
join tableNext c on b.Column = c.Column (you can also join to table a)
This will give you the data from both tables in one place, based on the staff ID. You can then join a column from the tableStaff table to another table and so on.
With this one statement you can run it and see how it puts all the columns into one table. If you put this code into a view, you can then access it. Furthermore, Excel has built in functionality to read the views you have created, and lets you refresh the reports by connecting to the database and then to the view.
Good luck!
Watch out for duplicates!
Related
I'm having trouble trying to make a conditional join within Power BI. I have Table A is the fact table. Table B is the table I'm trying to join.
Table A consists of transactions. Each transaction has a record with the method of the process (A,B,C).
The second table is a table of available options for the process method. These two tables come from different sources.
I'm looking for a way to join these tables where I can find the least expensive process method, AND so that a bunch of conditions are satisfied. For example, the In the transaction table, With Export Country CN and Import County US, two methods were used. I would like to join the MOST correct process method so I can determine how much money could have been saved if the correct method was used.
My assumption is that I have to create a new table using DAX and ADDcolumns and Summarize, but I would also need to using some nested conditioning and not sure where that comes into play.
Example, Join the minimum Process Method Cost from Table B where expiry < TableA.process date
Why not just create a view over Table B that has the minimum cost records and join to that?
I’m trying to get data about Installations in buildings. The problem is that one building can have multiple installations and I’m unsure how to adjust my sql for that as the initial table I query only holds the relations that own the buildings.
Here’s the situation.
Table 1 (RELRLGRP) holds the id of the group the relations that own the buildings that have the installations that have the data I need.
This is what I have so far, I’m worried I shouldn’t use this many joins in an SQL statement but cannot find a quicker link between the information I need from my starting point at the group of relations till the installation data I seek in the BORGINST table. Please disregard the select portion of the statement (removed it for clarity).
SELECT *
FROM RELRLGRP A
JOIN RELATION R ON A.RELATION_GC_ID = R.GC_ID
JOIN BUILDING G ON R.CODE = G.GC_CODE
JOIN INSTALL I ON G.GC_CODE = I.GC_CODE
JOIN BORGINST B ON I.GC_ID = B.GC_ID
WHERE A.RELGROUP_GC_ID LIKE '100109' (<- the group the relations belong to)
I’ve done some rudimentary SQL but this linking through tables is new territory for me, in that sense I’d be happy to know if this many join statements are the way to go or if I should head a different route entirely.
JesseJ - Since I don't know all the columns that exist in your tables, I am going to assume that you are joining on primary keys. If this is the case, your solution may be the only one available to link the RELRLGRP to the BORGINST table.
Linking multiple tables like you are doing can be common in a normalized database.
Example:
In the example I posted, in order to find the State where a particular transaction happened, you have to link all the tables together. There is no shortcut.
Don't sweat it: I have views with three times as many joins. Every join does add complexity and suck more processor, but it really comes down to performance: if this process doesn't finish as quickly as you need it to, you can look into other methods, but otherwise multiple joins like this are perfectly fine.
This and this made a great overview on joining three tables. But suppose we have a table Freights with fields From and To linked to Destinations table. In a Data Scheme I see Destinations_1 table, but when I try to use it in a query, it is not present. What to do?
Destinations_1 is the way Access internally aliases it. What you need to do is open the SQL window and manually alias it to something a little more distinct. There's no bigger pet peeve or worse coding offense than to let Access name everything for you. For instance, Field28 doesn't mean bubkus to the next guy coming in to take over your database, but txtStartDate will make it pretty simple to figure out what it holds. Similarly, Destinations_1 leaves the incoming coder pretty confused. Go into your SQL and fix this, so it looks more like:
SELECT * FROM Destination as PrimDestination
INNER JOIN Destination as SecDestination
ON PrimDestination.MyField = SecDestination.MyField
It will make much more sense to you once you see this layout, it will make more sense in the Design View, and it will make more sense to any future admin of the DB.
I have a view (View A) that pulls in columns from a number of tables. It also pulls in a column from another view (View B) which gets its data from a Linked Server table.
Now, View B runs fine, pulling back 11,000 rows in about a second. View A also runs fine. However, if I INNER JOIN from View A to View B on a column that comes from the Linked Server, the entire query runs so slow it times out.
If I INNER JOIN from View A to View B on a column that does NOT come from the Linked Server, it runs fine.
So I traced the issue to joining on a column which resides on the Linked Server. I just have no idea how to fix it.
Can anyone give me any pointers?
The circumstances were slightly different, but both my co-workers and I have seen evidence that if you have something like this:
select something
from LinkedServer.DataBase.Owner.Table
where whatever
then sql server will select the entire table from the other server first, and apply the where clause afterwards. That might be happening to you.
We solve the problem by using openquery instead of the fully qualified method shown above, and by putting the openquery results into a temp table. Then we join to the temp table.
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.