I want to create a query, according the some condition.
I have one program and one program has lot of packages. then package show according the condition that which package is assigned to contractor then it will show in one column. packages and amount will calculate in different column those package is assigned to contractor.
condition 1: if those packages is assigned to contractor. then this shows 1 in category column. and Stage of progress column shows Contract awarded.
then how many packages is assigned to contractor then will show in the Numbers. if contractor is not award then it goes to second condition.
Condition 2: some package is assigned to Bid Under Price Evaluation then show in one column and amount will also show in one column.
Condition 3: some package is assigned to Bid Under Technical Evaluation then show in one column and amount will also show in one column.
In second condition you did get the date then it goes to third condition and check there is technical date or not and that package will show in 3 category.
There is some formula on conversion rate.
Tables Name
tblPrograms (vsSysProgramId)
tblProgramsAndPackages (vsSysProgramId, iPackage)
tblPackages (iPackageId)
tblPkgContractAwardDetails (iPackageId, iCurrency)
tblCurrencies (iCurrencyId)
tblPkgDPRBidSubmissionDetails (iPackage, dtCEAgreement(date Column)
Example:
1.Stage of progress 2.Category 3.No 4.Packages 5.Amount(INR) 6.Amount(Jpy) 7.Amount(USD) 8.%Progress
Contracts Awarded I 2 Pac1,Pac2 100 50 200 Amount/totalamount
BidsUnderPrice II 2 Pac3,pac4 50 60 120
Total 4 150 110 320
It sounds like your problem is a mixture of determining the query or queries to use, and some rather complex report layout and formatting requirements.
Don't try to do both of these in T-SQL queries: you'll wind up with complex, slow queries that will be hard to understand and to debug, and even harder to enhance.
I assume that ultimately your data will be displayed somewhere, whether on a screen or on a report. My advice would be to use the features of your reporting tool or web page to evaluate your various conditions and determine what should be hidden or shown. Then, write queries, as simple as you can manage, to return the data needed for the conditions and for display.
T-SQL is not a report-writing tool, and it is not equipped to handle complex data formatting requirements. Those concerns are best left to tools like ASP.NET and SSRS, which can be as flexible as you need them to be in terms of layout, logic, and data formatting.
Related
I am looking for a way to store auto-generated reports. There are about 10-15 columns and 100-3000 rows depending on the report but each report is consistent in column count.
I am looking for a way to organise and store these reports into a large group without creating an entire new database and 1000s of tables to store each indervidual report.
The reports need to be queryable so they can be subdivided by team/area/person etc as each report can be a combination of 3-4 different sub-reports depending on how you split/sort the data.
I am using Python to collect and sort the data from the database so using MariaDB/MySQL would be preferred but im happy to use something else if there is a pre-exising connection libary for it.
To sum up i need something similar to a excel spreadsheet with each table being a sheet and sheet name being the date it was generated so i can select by the date generated.
Think through the goals.
Is this a legal issue -- you need to produce an unalterable report as something "official". A la a non-editable .pdf?
(at the opposite extreme) Be able to generate (or regenerate) any report for any timeframe.
Is performance an issue? (Either perceived or real)
I like to build and maintain Summary Table(s) for any "Data Warehouse" application. And build "reports" that take as a parameter a date range and a small number of other things. And have the report generation so fast that it does not matter if multiple people are pulling reports at random times.
15 columns and 3000 rows is usually excessive. If pulling a report is trivial enough, it can be less 'massive'; just get the parts you want, without such bulk.
http://mysql.rjweb.org/doc.php/summarytables
I have been tasked with creating a report that needs to display in chronological order, but within that report there is data from 2 sources that covers 2 different areas of business.
What I have been asked for, is when the type of business changes, the header row is repeated with the correct column headings for that type - i.e. :
Type 1 :
Order Ref / Sales Exec / Contract Term / Despatch Date / Agreement Type / Hardware ID
Type 2 :
Order Ref / Sale Type / Contract Term / Despatch Date / Start Date / Hardware ID
Also each header row should have a different background color by the type also (although I think I can do this already). Within the report the header row could be needed multiple times if the types flip from one to the other as the report traverses through the orders in date order.
I was first looking at adding a grouping by type, but that will interrupt the chronological flow of course.
Just to complicate matters there are different numbers of item columns for each type in reality, but I might have to just leave blanks where we have less columns for one type.
Or is there some way of having sub reports that are reporting for an "outer loop" of the actual order references?
It's almost like I need to construct the report in some sort of looped code.
How can I achieve this?
You can do this using table grouping. The outermost group would be by day and then within that you would group by type. Within that you can add a group that isn't grouped by anything so that it will list all the details depending on the number of records in the dataset. So the design would end up looking something like this:
This is how it looks when you run it.
Of course you can play around with how everything is organized, but the general structure should work for you. Or at least point you in the right direction.
I am a little new to building this but have come a long way.
I have built a db using Access 2007. I have a table that shows the employees info:
Lname
Fname
Status
HireDate
TermDate
(Status: they are either inactive (potential Hires), Active or Terminated)
I can run a query that will show me all the employees by hire date or run one to show term dates.
We would like to have a query that will give us a count of how many drivers are still there within a given month.
Say Joe Smith was hired on 01/01/2008 and was terminated on 05/15/2011. If I ran a report in 2011 on May 31st how would I need to build the query to show this employee as being there in the month of May?
I have used >=Date() and others. I could use between #05/01/2011# and #06/01/2011# in the criteria under TermDate but if there is not a date there, nothing shows up. I have even dropped down a line and added "Null" and still nothing or I get all the employees that are still there and the ones that was terminated before the dates. I'm not sure what I am doing wrong.
I'm unsure about the logic for the filter criteria on this one. I think your goal is to identify all drivers who were on staff during any part of May 2011. My best guess is you need at least 2 conditions to identify them.
HireDate prior to June 1, 2011
TermDate either Null or >= May 1, 2011
If those conditions are sufficient, the SQL could be fairly easy.
SELECT e.Lname, e.Fname
FROM employees_info AS e
WHERE
e.HireDate < #2011-6-1#
AND
(
e.TermDate Is Null
OR
e.TermDate >= #2011-5-1#
);
It sounds like you're building the query in Design View ... which is a good and helpful feature. However, it's difficult to describe how to build that query in Design View. So I suggest you create a new query, switch to SQL View and paste in that SQL text. Replace employees_info with your actual table name, and fix any field names I misspelled.
If that query runs without error, you can flip back and forth between Design and SQL view, make a change in one, and examine how it is represented in the other view.
The SQL doesn't have to be formatted the way I wrote it. I chose that way in hopes it would make the WHERE logic clear. And if you make changes to the query from Design View, Access will reformat the SQL as it sees fit. However, the formatting change should not break the query.
I used yyyy-m-d format for the literal date values. That format avoids any possible confusion over which parts represent day and month, such as whether #05-01-2011# is intended to represent May 1st or Jan 5th. However, when you alter the query, Access may change them to mm-dd-yyyy format. (Sometimes its "helpful" impulses are annoying.)
I'm puzzled about one point. It seems you have one record per employee. If that is so, and an employee can leave for any reason and be re-hired later, it would be difficult to capture the different employment terms in a single record. If you're facing that situation, you may need to revise table designs.
If I misinterpreted your data, please show us a brief data sample, and the output you want from the query based on that sample. Good luck with this.
Using Standard SQL, how do I make a report with a top title?
Last year I participated in a Database competition. The description said I could use MySQL, Oracle, or MS SQL Server. I choose MySQL because that is what I am familiar with. It said that I must write an sql statement using Standard SQL that will work in any of the listed DBMS. I have searched google, but no luck on finding any tutorials or anything related to the issues below. Any suggestions on where to look or what to search would be great.
Group by and perform a control break on the plan ID (skip one line
after the break).
Insert a top title and bottom title as shown.
Set your page size to
30, and the width of the line to 65.
Column 1 has a width of 10, Column 2 has a width of 15, Column 3 has
a width of 15, and Column 4 has a width of 20.
The expected formatted report is shown below:
The comments above to the question not withstanding, 18 months ago I had to build 2 queries similar to this for a real-world reporting application. The requirements were unusual, and for an unusual reporting environment, but none-the-less were quite sane and sensible. The end-product of the query was then spun into MS-Access for final reporting and printing. It was quite fun to program actually.
Using SQL Server, the SQL dialect I am most familiar with, the report can be built as follows.
Note that of the 30 lines for the report outlined 20 are data rows, and 10 are page header, columns header, or page footer rows.
Build a query for the main data grouped on Plan Id that outputs each field converted to a varchar of the requisite length.
Build a super query over (1) that generates a single 65 character text string as each row output
Buid a super-query that groups (2) on PlanId with a test on grouping(PlanId) that generates empty strings in every column;this is the blank line after each PlanId group.
Build a super-query over(3) that assigns a sequential RowNumber to each row, and then calculate fields PageNumber = floor(RowNumber / 20) and PageSequence = RowNumber mod 20.
Manually build the header/footer rows with appropriate PageSequence values, and cross join to the distinct values of PageNumber from (4).
Union All (4) and (5) with an appropriate Order By clause.
Etc.
The actual application where I had to apply these techniques required creating an MS-Access report that had an indefinite number of pages running out horizintally, with 6 numeric columns and 1 descriptive column per page, with the final numeric column being a total of all previous numeric columns. The whole report was three of these, each starting on a new page, but each with a different number of numeric columns. Because of how the raw data was stored on the SQL Server, and the slow data link, it was much more efficient to run the whole report as one query than three separate ones.
Have fun.
P.S.
Because of other project constraints, I had the benefit of dynamically creating this SQL using a SQL-macro facility similar to that of old-style C; hand-rolled of course, because who ever heard of such a thing. When you can write it that way, it ALMOST looks structured.
I'm going through cleaning up old questions. For anyone who might be curious, I actually used PL/SQL for the competition. Worked great for creating "reports" directly in SQL. http://www.oracle.com/technetwork/database/features/plsql/index.html
This is quite a strange problem, wasn't quite sure how to title it. The issue I have is some data rows in an SSIS task which need to be modified depending on other rows.
Name Location IsMultiple
Bob England
Jim Wales
John Scotland
Jane England
A simplifed dataset, with some names, their locations, and a column 'IsMultiple' which needs to be updated to show which rows share locations. (Bob and Jane's rows would be flagged 'True' in the example above).
In my situation there is much more complex logic involved, so solutions using sql would not be suitable.
My initial thoughts were to use an asyncronous script task, take in all the data rows, parse them, and then output them all after the very last row has been input. The only way I could think of doing this was to call row creation in the PostExecute Phase, which did not work.
Is there a better way to go about this?
A couple of options come to mind for SSIS solutions. With both options you would need the data sorted by location. If you can do this in your SQL source, that would be best. Otherwise, you have the Sort component.
With sorted data as your input you can use a Script component that compares the values of adjacent rows to see if multiple locations exist.
Another option would be to split your data path into two. Do this by adding a Multicast component. The first path would be your main path that you currently have. In the second task, add an Aggregate transformation after the Multicast component. Edit the Aggregate and select Location as a Group By operation. Select (*) as a Count all. The output will be rows with counts by location.
After the Aggregate, Add a Merge Join component and select your first and second data paths as inputs. Your join keys should be the Location column from each path. All the inputs from path 1 should be outputs and include the count from path 2 as an output.
In a derived column, modify the isMultiple column with an expression that expresses "If count is greater than 1 then true else false".
If possible, I might recommend doing it with pure SQL in a SQL task on your control flow prior to your data flow. A simple UPDATE query where you GROUP BY location and do a HAVING COUNT for everything greater than 1 should be able to do this. But if this is a simplified version this may not be feasible.
If the data isn't available until after the data flow is done you could place the SQL task after your data flow on your control flow.