I have a fully functional DB developed in Access. It was done using a very "interactive" developer-client increment-iterative process as no one really knows what the final DB is to show. All tables were developed (and normalized) as well as forms (and sub-forms), however, now reports must be designed and implemented.
The forms of course, are based on queries which take the criteria from the form itself to run the queries and show information in the subforms. Now, as in practice, the reports have to basically be pretty printable versions of the on-screen forms for distribution. From my research, the reports are also based on queries, but since the queries I have are using the fields from the forms to display the relevant information in subforms, I don't see anyway to create these reports unless I basically duplicate all my queries to not pull values from forms. This seems very tedious and inefficient. Is this the "best practice" way to create reports for a database?
V.K.
You can put a button on the form which launches the report using the same query. The report query will then use the fiels/query from the form, and should then return the same result set.
Hard-coding form fields in a query is the problematic part here -- that's definitely not "best practice". I guess you need these values in your WHERE clause? What you could do is to remove the field references from your queries (so that the query returns all records). In the Subform or Report, don't use the query directly as the record source. Instead, use some SQL that accesses your (generalized) query and and additional filter criteria. For example, the record source of your subform could be
SELECT * FROM myQuery WHERE someQueryField = Me.Parent!SomeFormField
allowing you to use the same myQuery with a different WHERE clause (which does not reference a Form) in your report.
I'm not sure I'm understanding your question, but having recently worked with an app that used a form to drive a report, I might have an inkling.
You don't want your report tied to the single record of the form. You want your report to use the same recordsource as the form, insofar as they are displaying the same data, of course.
The reason for this is that if you hardwire your report to the form fields, the report can't be used except when the form is open, and it can't display anything but one record.
If you create your report so it loads all records, then you'll need to be able to print one record at a time, and for that you just use the WHERE argument of the DoCmd.OpenReport command, using the PK value as your criterion.
So, yes, you should use the same recordsource. Why would anyone consider that a problem?
Related
I have 2 reports in the WEBI document, for every report, i need to use different SQL
I tried to create another report with different SQL, but it changed the same query to the first report.
Second questions :
I need to display some rows in different colors based on the amount. how to do it.
thanks
When you have more than one question it would be better to post them separately.
1. Multiple Queries
If you want a query with different SQL you need add another query from within the Query Panel.
By default it will be named "Query 2". If you are running a query for the first time WebI will put all of the Result Objects on your report. Otherwise you will need to manually add them to your report.
When I have multiple queries I always change the view at the bottom of the Available Objects pan to "Arranged by Query". Also, if you have the same object name in more than one query WebI will qualify it with the query name.
2. Different Colors Based on Value
You want to do what is referred to as Conditional Formatting. Here is YouTube video on that. The link for that video came from the SAP BusinessObjects Web Intelligence link on the Official Product Tutorials - SAP BusinessObjects BI Suite website. I would recommend you spend some significant time reviewing the information there.
StackOverflow is very focused on code. Your questions are more about how to use Web Intelligence. Those types of question would be a better fit for the BusinessObjects Board.
Noel
From the menu bar Analysis -> conditional -> new rule ..
You can create different rule (specify rule condition in it ) and for each rule you can give particular formatting option.
[Webi]enter image description here
After selecting the column for which u need to apply the rule press FORMATTING Rules and check all the rules you need to apply .Hence you can achieve different color for different value (by assigning different rule )
I have a SSRS Sales report that will be run many times a day by users, but with different parameters selected for the branch and product types.
The SQL query uses some large tables and is quite complex, therefore, running it many times is going to have a performance cost.
I assumed the best solution would be to create a dataset for the report with all permutations, ran once overnight and then apply filters when the users run the report.
I tried creating a snapshot in SSRS which doesn’t consider the parameters and therefore has all the required data, then filtering the Tablix using the parameters that the users selected. The snapshot works fine but it appears to be refreshed when the report is run with different parameters.
My next solution would be to create a table for the dataset which the report would then point to. I could recreate the table every night using a stored procedure. With a couple of small indexes the report would be lightning fast.
This solution would seem to work really well but my knowledge of SQL is limited, and I can’t help thinking this is not the right solution.
Is this suitable? Are there better ways? Can anybody confirm either way?
SSRS datasets have caching capabilities. I think you'll find this more useful instead of having to create extra db tables and such.
Please see here https://learn.microsoft.com/en-us/sql/reporting-services/report-server/cache-shared-datasets-ssrs?view=sql-server-ver15
If the rate of change of the data is low enough, and SSRS Caching doesn't suit your needs, then you could manually cache the record set from the report query (without the filtering) into its own table, then you can modify the report to query from that table.
Oracle and most Data Warehouse implementations have a formal mechanism specifically for this called Materialized Views, no such luck in SQL server though you can easily implement the same pattern yourself.
There are 2 significant drawbacks to this:
The data in the new table is a snapshot at the point in time that it was loaded, so this technique is better suited to slow moving datasets or reports where it is not critical that the data is 100% accurate.
You will need to manage the lifecycle of the data in this table, ideally you should setup a Job or Scheduled Task to automate this refresh but you could trigger a refresh as part of the logic in your report (not recommended, but possible).
Though it is possible, you would NOT consider using a TRIGGER to update the data as you have already indicated the query takes some time to execute, this could have a major impact on the rest of your LOB application
If you do go down this path you should write the refresh logic into a stored procedure so that it can be executed when needed and from other internal and external automation mechanisms.
You should also add a column that records the date and time of when the dataset was executed, then replace any references in your report that display the date and time the report was printed, with the time the data was prepared.
It is also worth pointing out that often performance issues with expensive queries in SSRS reports can be overcome if you can reducing the functions and value formatting that is in the SQL query itself and move that logic into the report definition. This goes for filtering operations too, you can easily add additional computed columns in the dataset definition or in the design surface and you can implement filtering directly in the tablix too, there is no requirement that every record from the SQL query be displayed in the report at all, just as we do not need to show every column.
Sometimes some well crafted indexes can help too, for complicated reports we can often find a balance between what the SQL engine can do efficiently and what the RDL can do for us.
Disclaimer: This is hypothetical advice, you should evaluate each report on a case by case basis.
I have a handful of fields linked to a subform (in datasheet view) on my mainform and I would like to be able to edit the data in the table from the fields since the subform is very wide and hard to see all of it. The subform is pulling data through a query to put multiple tables together and I think that's what's preventing me from editing the data from the fields based on what I've seen. The SQL statement that links the fields to the subform is like the following for several fields:=[SubformX].[Form]![Data] I was wondering if some kind of VBA/Query would be able to directly populate the fields based on the subform selection and still allow it to be edited or if there is a simple fix for this problem.
Due to natural limitations on updating data from a form, it seems this approach is not workable without using VBA to stage the update and display. Refer to the comments above for some detail.
I am trying to understand a couple concepts with ADO.net and access. I understand how to query a table or set a record using ADO, and I have looked at various online articles pertaining to pulling tables and handling queries. I am wondering what the relationship is between VBA Forms, DataSheets and Tables.
Am I to understand that a UserForm can contains a DataSheet? And is that essentially a table but seperate? Changing from "Form View" to "DataSheet View" shows me the information being logged in the form. Yet, sorting the navigation view by "TABLE" will not bring up the same information as is logged into the DataSheet.
How would ADO access information from within a DataSheet object and not necessarily a table? Thanks for any advice.
A datasheet is a form. You can remove the Record Source altogether, you will still have a form. It is not uncommon to set the recordsource property of a form at runtime.
Access can work very well indeed in a number of situations. Do not be put off by bad press. The only reason to change is that the current set-up is not working -- because it has grown too big, because the company has grown too big, etc. Even some of these cases can be dealt with by keeping the (working) front-end and replacing the back-end (database) with something more robust. For the most part, problems with Access are not do do with the front-end but to do with the small-office sized database that is Jet/ACE.
The site I am working on as a student will be redesigned and released in the near future and I have been assigned the task of manually searching through every table in the DB the site uses to find tables we can consider for deletion. I'm doing the search through every HTML files source code in dreamweaver but I was hoping there is an automated way to check my work. Does anyone have any suggestions as to how this is done in the business world?
If you search through the code, you may find SQL that is never used, because the users never choose those options in the application.
Instead, I would suggest that you turn on auditing on the database and log what SQL is actually used. For example in Oracle you would do it like this. Other major database servers have similar capabilities.
From the log data you can identify not only what tables are being used, but their frequency of use. If there are any tables in the schema that do not show up during a week of auditing, or show up only rarely, then you could investigate this in the code using text search tools.
Once you have candidate tables to remove from the database, and approval from your manager, then don't just drop the tables, create them again as an empty table, or put one dummy record in the table with mostly null values (or zero or blank) in the fields, except for name and descriptive fields where you can put something like "DELETED" "Report error DELE to support center", etc. That way, the application won't fail with a hard error, and you have a chance at finding out what users are doing when they end up with these unused tables.
Reverse engineer the DB (Visio, Toad, etc...), document the structure and ask designers of the new site what they need -- then refactor.
I would start by combing through the HTML source for keywords:
SELECT
INSERT
UPDATE
DELETE
...using grep/etc. None of these are HTML entities, and you can't reliably use table names because you could be dealing with views (assuming any exist in the system). Then you have to pour over the statements themselves to determine what is being used.
If [hopefully] functions and/or stored procedures were used in the system, most DBs have a reference feature to check for dependencies.
This would be a good time to create a Design Document on a screen by screen basis, listing the attributes on screen & where the value(s) come from in the database at the table.column level.
Compile your list of tables used, and compare to what's actually in the database.
If the table names are specified in the HTML source (and if that's the only place they are ever specified!), you can do a Search in Files for the name of each table in the DB. If there are a lot of tables, consider using a tool like grep and creating a script that runs grep against the source code base (HTML files plus any others that can reference the table by name) for each table name.
Having said that, I would still follow Damir's advice and take a list of deletion candidates to the data designers for validation.
I'm guessing you don't have any tests in place around the data access or the UI, so there's no way to verify what is and isn't used. Provided that the data access is consistent, scripting will be your best bet. Have it search out the tables/views/stored procedures that are being called and dump those to a file to analyze further. That will at least give you a list of everything that is actually called from some place. As for if those pages are actually used anywhere, that's another story.
Once you have the list of the database elements that are being called, compare that with a list of the user-defined elements that are in the database. That will give you the ones that could potentially be deleted.
All that being said, if the site is being redesigned then a fresh database schema may actually be a better approach. It's usually less intensive to start fresh and import the old data than it is to find dead tables and fields.