I am using Crystal Reports 8.0.1.0 and have an OLEDB connection set as "favourite".
We have several reports being run against a few stored procedures on the database.
Our database is an SQLExpress 2005 named instance.
One of the reports deals with balance, i.e. we have to provide a balance report for a specific company or set of companies.
The customer, however, has specifically asked us to have a separate section to be the last one for a specific economic account typology and in order to do this, we have to separate this one from the others which are instead displayed using two parallel subreports.
Hence our structure should be like follows:
GENERAL HEADING
PATRIMONIAL STATE
...data...
ECONOMIC COUNTS
...data...
THIRD-PARTY EFFECTS
...data...
The first two sections below the general heading are achieved with two parallel subreports, so now we have to display the third section.
Is it clear up to now? Well, as you may well be aware, CR subreports require you to set the database location, regardless if you have set one up already for main report.
The problem, however, is that if I try to set the location pointing to our stored procedure(which returns ALL the data for the balance report), the first time it will display the message in subject, and the second time again, but this time it'll also crash.
Our stored procedure has a parameter and both previous subreports(the ones in parallel) are set to the same SP and are working flawlessly.
This crash makes it impossible for me to work on the third section and I'm pretty much at loss as to what would be the best approach to solve the issue at hand.
Any ideas/suggestions?
I would love to receive your answers and I hope my problem was clear enough(I'm very willing to further delve into it for clarification if ever needed).
Thank you so much for your time,
Andrea Raimondi
Geez... changing the connection from OLEDB to SQLServer it correctly fetches the rowset and doesn't crash!
I am speechless.
Andrew
Related
I was wondering if anyone had a method of running a report to see what a user is doing in Epicor or what they are printing. We are having users report that in the middle of the night, when no one is here at the plant, there are 500 page reports being printed. We are able to see in the print queue who printed what, but the report doesn't match up with anything in our system. We would have for example a report called DailySales.rpt, but in the printer queue it would be something like hb986a87dthr.rpt. Just wondering if anyone else has seen this, or would have a solution that would let me see what a user is printing.
It is not possible to link the print job directly to the SysTask record because neither the print job number, the temp file, nor mac addresses are saved in Epicor for cross referencing. It can be approximated by looking at runtimes and the SysTask record.
You can create a BAQ and BAQ report to display Active and recently completed SysTask information by user. This will give you the report run, start/end times, user, and current status. If you need more detailed information such as the criteria used in the report, you can also join to the SysTaskParam table. Keep in mind that the SysTaskParam table is fully normalized by field name, so you may want to join multiple copies of the table with specific criteria if you need a lot of information. Unfortunately, for "print all pages" jobs, Epicor doesn't know how many pages the report will be until after the data is instantiated and then it is rendered in the reporting software, so you won't be able to get any estimate of number of pages or size.
There are many strategies for mitigating the issue you described. Here are a couple:
You can use criteria within the BAQ to limit the number of records returned for a specific query
You can create a subquery criteria from BAQ parameters to return no data when abnormally open parameters are used for the report (e.g. > 30 days range). You could also use this method with time gates based on the current system time.
Retrain users
I have an access project that is "linked" to a SQL database that now works like a charm. The last problem I solved was, making sure any Boolean fields be turned to bits with default of 0, and adding the TIMESTAMP in SQL due to the fact that ACCESS is not so much of a genius with record locking (so I was told) .
Now that I tried to connect direct to SQL server by using an ADODB.Recordset and setting the forms.recordset to the recordset, at the OnOpen event of the form, (this recordset runs a stored procedure in SQL, I get the data fine but get the error locking (write conflict) back.
This ADODB.Recordset cursorlocation is set to "adUseClient".
Obviously I no longer have the forms recordsource attached or assigned to the linked SQL table anymore.
Am I missing something? do I need to assign anything to the forms recordsource?
The Idea is trying to connect directly thru the use of stored procedures instead of linked tables.
thanks so much for any help.
The adding of timestamp is a VERY good idea. And do not confuse the term/name used timestamp to mean an actual date/time column. The correct term is "row version".
This issue has ZERO to do with locking. The REASON why you want this column added is because then Access will use that column to determine when the record is dirty, and more imporant figure out that the record been changed. If you omit this column, then access reverts to a column by column testing approach. Not only does this cause more network traffic, but worse for real type values, due to rounding, you can get the dredged this record has been changed by another user. But, it not been changed, and even columns with floating point values will cause access to error out with that changed record.
So, for all tables, and you even see the option included in the SSMA (the access to sql migration wizard that this option is available (and I believe it is a default).
So yes, it is HIGH but VERY high recommended that you include/add a rowversion column to all tables - this will help Access in a HUGE way.
And as noted, there is a long standing issue with bit fields that don't have a default setting. so, you don't want to allow bit fields to be added/created with a null value. So, ensure that there is a default value of 0 (you set this sql server side).
Ok, now that we have the above cleared up?
It not really all that clear as to why you want or need or are adopting a store procedure and code to load/fill up the form. You not see any better performance if you bind the form DIRECTLY to the linked table. Access will ONLY pull the reocrds you tell that form to load.
So, bind the form directly to the linked table. Then, you can launch/open the form say to once reocrd with this:
docmd.OpenForm "frmInvoices",,,"InvoiceNum = 123"
Now, you would of course change the above "123" to some variable or some way to prompt the user for what invoice to work on.
The invoice form will then load to the ONE record. So, even if the form bound (linked table) has 2 million rows? Only ONE record will come down the network pipe. So, all that extra work of a store procedure, creating a recordset and pulling it ? You will gain ZERO in terms of performance, but you are writing all kinds of code when it simply not required, and you not achieve any superior performance to the above one line of code that will automatic filter and ONLY pull down the record that meets the given criteria (in this example invoice number).
So:
Yes, all tables need a PK
Yes, all tables should have a rowversion (but it called a timestamp column - nothing to do with the actual time).
Yes, all bit fields need a default of 0 - don't allow null values.
And last but not least?
I don't see any gains in performance, or even any advantages of attempting to code your way though this by adopting store procedures and that of introducing reocrdset code when none is required, but worse will not gain you performance anyway.
I'm currently going through all of our Crystal Reports and changing them to read from Stored Procedures instead of having the joins/tables inside of the report itself.
The problem is, I have to manually remove then add the fields. Is there a way to programmatically or mass change the report fields to avoid wasted man hours? Assuming each field on the report exists by a (slightly) different name in the stored procedure.
Unfortunately there isn't an easy way to do this. You can try going to the database, set datasource location and replacing each table with the stored procedure. Each time you do this you should be prompted to map each field that doesn't have a corresponding entry with the same field name.
Though I think crystal will try to alias the sproc multiple times instead of point all to the same sproc.
I meant to elaborate... When you come to designing more complex reports it's a kind of "best practice" to create formula fields for EVERY field you use in your report. This makes life a lot easier when coming to do something like this in future
Is it at all possible using CRM 2011 and SSRS to generate a report on a single record, and only get results for that one record?
EDIT
Additional Info - Must Use:
Custom SSRS report
Custom entity in CRM
Here's a more specific link to your question: link. You're probably looking for pre-filtering (look for "3. Pre-filtering Element" in the link provided) if you want the report to be record specific (context sensitive).
Here's a link describing the 2 types of pre-filters (CRM 4.0 but the theory applies to CRM 2011): link. And here's an example of prefiltering in CRM 2011: link
I have done this successfully in CRM 2011 with a completely custom report made in BIDS, on a custom entity, with full context sensitivity.
Make sure to learn fetchXML as it's going to be the going forward technology for these reports. The existing reports are using SQL which make them bad examples to copy off of.
Here's an example on how to extract fetchXML from an advanced find: link It also has more information on pre-filtering.
Take a look a the report Account Overview.rdl. It could be executed for a single account record or multiple records.
See Reporting for Microsoft Dynamics CRM Using Microsoft SQL Server Reporting Services
Create an embedded connection to the CRM database engine for the environment you want to target.
Create an embedded dataset to query the current record. This going to be kind of weird since experience will tell you that you are going to get tons of records, but because of the clunkiness behind CRM it will actually only get the current record. For example, if you wanted to get the current quote you would use "SELECT quoteid FROM FilteredQuote AS CRMAF_Quote"
Add a parameter to store the reference to the entity you just queried. In keeping with this example I created #QuoteFilter which is type text, could store multiple values (even though that's not what we're using it for), and gets its default value from the dataset in step 2. Also, probably ought to make this hidden since GUIDs aren't end user friendly.
Finally, use the parameter discovered in the where clause of the other datasets. For example, a search on quote products for the current quote would look something like SELECT * FROM FilteredQuoteDetail WHERE (quoteid = #QuoteFilter)
As a final note, you should keep in mind that CRM loves to remember everything even when you don't want it, too. On one of my reports I messed up my datasource and CRM was forever convinced that the report should run against all records. I fixed my datasource, but uploading the report did not trigger a refresh and correct the problem. In the end, I deleted the report from CRM, created a new one, uploaded the same exact file with no changes, and everything worked. Go figure.
In Crystal Reports, is there a way to get both full set charting and subset charting, in the report headers?
I'm working on a report from an erstwhile co-worker and I'm still trying to make things "better".
While I haven't found the solution to accruing time
( see Accruing over time (non-overlapping) - technique? )
I'll press on with how to use the resulting data once I retrieve it.
The report is a Global Availability report for network technologies, and part of the report is graphic:
Chart availability for different
network types for last "n" months'
time.
Charts availability for each region
(for each network type for "n"
months' time).
She (co-worker) had a global chart, but for each region, she did a separate sub-report containing just the chart for that region. The query isn't optimal, and using the sub-reports, the query is repeated each time.
If there a way to use a single data-set in one report for all five charts, forcing the four regional charts to display only that region's data?
Additional info:
The charts are all Bar charts, design is
y-axis: calculated availability
x-axis: Group by network type (Switches, Trunks, "Network)
sub group by month
Bad Example:
Let me see if I understand this. In your Report Header, you have 5 Subreports for the 4 regional graphs and the global graph. And you want to collapse this all into 1 Subreport if possible?
Yes, but you can't do it like in your image where United States & Europe are side-by-side. They would have to be 1 per row. Also, the datasource also has to be formatted correctly. To do this,
Make a new subreport. Group it by the Region.
In this subreport, make your regional graph in the Group Header section.
In this subreport, also make your global graph in the Report Header section.
Insert this subreport into your main report and you should be done.
Sometimes, the only way out of the fire is through it.
After lots of un-satisfactory refactoring, I spoke with the original (years ago) requestor and got some good information. I have yet to speak to the most recent requestor again (who didn't have any knowledge of the technical requirements the last several times).
Spoke w/ the guy who is tending a related db, and I get permission to add come functions, views, store procedures, etc. to THAT db... Within reason and after code/perf review -- something that isn't normally conducted, so I welcome it. I WILL have the ability to do the procedural stuff through... a procedure. Written as a stand-alone, I should be able to re-use it for any of the queries against future needs.
And... Yes, I am pretty much going to have to (read "get to") re-design, and hopefully get rid of most of the sub-reports. Yeay, me.
Thanks for coming along for the ride.