I have a report in SSRS that contains many textboxes that pull data from our Epicor 10 database. One in particular only displays the first 30 characters. In our ERP system, the field format is x(16000) so the user can enter quite a bit of data. The textbox size is definitely large enough to contain more than 30 characters (it's about half a page wide). I enabled the "Can Grow" option, and I've expanded the text box box horizontally and vertically, but still, only the first 30 characters display.
Typically, the text in this field begins with a number (these are shipping comments so it will say, for example, "2 Skids #60 boxes... etc.). That's the only real difference I can find between this particular text box and the other ones on the report that display the entire field value. Am I missing some Option, or do I need to convert the field in some way?
Thanks in advance.
Pull up your report in System Management | Reporting | Report Data Definition and check to see if it is a Calculated field limited the number of characters as Hannover Fist has posited. Searching the table Ice.RptCalcField I see a number of out of the box things that limit to x(30), but I don't see anything larger than x(2000). There are couple of DataFields in Ice.ZDataField that are that large, so I am assuming this isn't an out of the box sort of thing.
If the Data Definition field is set to x(16000) try changing it to x(100) and see if that makes a difference. Maybe the value you have is large for the printing framework and it is reverting to some sort of default.
Good luck, I would be interested to see how this turns our for you as we may eventually run into a similar problem.
Related
I am using Access 2013.
I am generating a specifications writing database which involves the user inputting a number of items as data which is then incorporated into a report. The report structure is largely similar but there are something like 30 variants with small changes based on the data entered at the start.
Each report extends to around 7 pages whereas the data is only in the first 2 pages. The remaining pages contain standard clauses common to all the reports. effectively they are an instructional on using the products to which the specification report refers.
I now have a rather frustrating problem.
Is it possible please to set up a standard report using a rich text format. I have thought of using the bulk of the report as an image and incorporating this but it uses up lots of storage space. I have looked through the forum but cant find a scenario that really fits what I am looking for..
I almost want a really big text box that I can format in the same way as you would a word document. Not sure if this makes sense so if further clarification is required please ask. Many thanks in anticipation.
You can use Rich Text in Access, with the data stored in a Memo (Long Text) field: Link
I would set it up like this:
Have a table with one field per clause. This table has only one record. Fill out the texts directly in the table (or build a simple form for it, if you like).
In your record source of the report, add this table without any join (= cross join).
Then add all the fields to the report footer, height = 1 line, Can grow = True.
This will keep each clause together on a page. If you don't care about this, you can also use one huge field with all the text.
I have an MS Access report that crashes when the mouse wheel is used to scroll through the report in view mode. I've been verbose. For a quicker version, read bold text only.
Before I go further, when I say crashes Access, I mean a spinning wheel pops up and Access becomes unresponsive (i.e. "Not Responding"). The only way to get out of this state is to force Access to close. No error codes or explanation are given.
This problem only occurs in report view mode. If I open the report in design, layout, or print mode there are no issues. The issue only occurs when using the mouse wheel. Scrolling with the vertical scroll bar or arrow keys poses no problem. This issue is repeatable across users on different machines with different mice. Though it is likely we're both running Access 2016 and Windows 7 Enterprise SP1. I have not configured any "on mouse wheel" vba code anywhere in the database.
The report itself contains ~20 fields, 2 very simple subreports (single tables with 2 columns liked off a single field on the main report), and a rather lengthy report body with 3 layers of grouping and roughly 150 rows sprinkled among the various groups. The rows are retrieving longer memo fields (hundreds of characters per row).
In addition, I have added a field that numbers each row (text box with control source=1, configured as a running sum "over all"). Oddly, if I delete the running sum text box, the problem goes away. If I add it back again, the problem returns. This is the only calculated field in the report. All of the other data originate from queries. I should point out that the report worked fine with the field that numbered each row prior to adding the two subreports. So it seems that the combination of counting from 1 to 150 + subreports is overwhelming Access. [This is surprising to me given that my database is fairly small - 15-20 tables with less than 1000 rows total.]
Configuration of text box that seems to be causing the problem
Has anyone seen this problem before? Does anyone know of a work around I could use to number each row versus just storing the row number in a table? [I don't want to do it this way because I'd like the numbers to remain sequential and in order when a user adds or deletes a row or if a subset of rows is queried. I could write code to detect changes and renumber, but I'm hoping for something simpler.]
I have been tasked with cleaning up some outstanding issues with my company's invoices. It is a very complicated report (four separate invoice formats are combined and determined conditionally because the application that calls them only allows 1 invoice format). I am going to try to keep this limited to just the current issue, but will provide as much info as necessary to solve the issue.
There are tons of existing questions about repeating group headers, like this one and they have helped me solve most of my problems, but I have not seen the problem I am still having addressed. I am sorry if I missed it!
The issue: The last tablix on my report is finally repeating the headers on all pages, but I now have the issue where when there is enough room, the header will display in the middle of the page below the second to last tablix.
Unfortunately, adding a page break breaks the page numbers even with reset page number set to false. (I have explicitly added the xml tag and it still resets)
What is the best way to only show the group headers at the top of the page when there is extreme variability in the size of many elements in the report (note fields that vary between one short line and epic novel length and images that vary in physical size and quantity).
Thank you for taking the time to read and help with my issue, I will continue searching through the similar questions that writing this prompted.
I will wait to accept this as THE answer, in the hopes that someone out there has a brilliant solution that has escaped me.
Based on comments here https://www.mssqltips.com/sqlservertip/3482/sql-server-reporting-services-ssrs-controlling-report-page-breaks/#comments
It appears my options are:
1. Accept that some pages will have two headers
2. Accept multi-page reports displaying page 1 of 1 on every page
3. Rework the report to not use a subreport
Thank you to everyone who has taken the time to consider my problem!!
#WhatEva sorry about the slow reply; am in and out of work this week and next. Capsule response: imagine the final, correctly formatted report, and imagine that you have all the text (non-header, non-footer) data in a single table. Add group columns as necessary to allow you to trigger the relevant headers and footers. You're likely to need a sequence id column to govern the order of printing of the rows. The report you're trying to write would have generated the text body fields; rewrite the report data sets as SP procedures to insert those text rows into the table, and ensure the group columns are filled out suitably to generate the right headers etc. Then write an SSRS report to pull that data and use the usual mechanisms to manage the headers and footers. It's hard to be more specific without knowing details, and there are certainly limitations on this approach, but it can solve some problems.
I'm currently in the process of coding a summary report in Access XP for a client and while for the most part I've gotten 99% of the fields to match correctly with the original report (created in Corel Paradox 4.0), I'm having an issue with a sum field where despite using the same set of data, I'm getting invalid answers.
For example, in one table, the sum of the fee field comes to 9,050 in the Paradox report. In Access, the table containing the data also comes to that same amount. Despite this, when I enter the expression in my Summary report, Access will always display the total as 9,005.
I've been trying to use the NZ function to cancel any nulls, however that hasn't helped. Changing the number format to currency, general, and other formats also hasn't been helping.
Any assistance/insights are greatly appreciated.
EDIT: As requested below are some of the expressions from my Access report. Everything up till now has strictly been Access code, but as I have SQL experience, I am open to implementing that type of code if needed (it actually has been on my mind for a bit)
=nz(Sum([Fee]))
Calculates just the total fees
=nz(Sum([Room & Meals]))+(nz(Sum([Commutter & Meals])))+(nz(Sum([Fee])))
This we use to calculate the grand total. It also comes out identical to the fee total for my dummy data since the first two fields don't have any totals added to them.
Not sure this will help, but you need to break this down to trouble-shoot.
Capture the detail data from this report and compare to the Corel Paradox data. Don't just test the totals. Maybe you can put them in Excel.
Break out the three fields individually and sum those: Sum([Room & Meals, Sum([Commutter & Meals, Sum([Fee]). Don't format. Manually add them together to test.
Are these integers or is there some rounding going on?
Are the text boxes on the report large enough to display the entire number?
1 may show you're comparing apples to oranges.
I am working on Audit Trail for my project and I have been asked to think of how can we display the fields which have changed between two versions. I have the list of changed fields I am looking for suggestions on how to display the fields so that user can easily find out:
which fields have changed
what was the old and new value
A simple approach will be to display the old and new values in grid with the top row showing new values and the bottom row showing the old value.
But this one is very basic approach
another one i thought of was to display the changed fields in color so that the user understands that these fields have changed but in this case he will not be able to get the old value of the fields.
If any one has some innovative ideas kindly let me know.
Thanks
Your idea of showing colours would be a good visual aid, but perhaps a list of changed values below the main record would also be beneficial, so you could have an "at a glance" view.
Something akin to:
Firstname: Phil -> Philip
Email: phil#example.com -> phil#someotheremailprovider.com
A bit more innovative, but non standard so potentially open to usability/training issues, would be the coloured input field that when you mouseover/focus launches a bubble to the side with the old value.
Several possibilities come to mind whose suitability depends on the user’s task (doesn’t it always?):
Task: Get a general quick overview of how things have changed in a window. Here the user needs to compare the old values along with the new, but doesn’t necessarily need to check every single field.
Design: Provide a toolbar button and/or accelerator key that swaps the new values with the old. If this can be done instantly (<500ms), the apparent animation will naturally draw the user’s eye towards places where the greatest changes were made. This is especially effective if the content is graphical (e.g., slider values, graphs, or editing an image)
Task: Crosscheck every change of every field to make sure new values are correct. In this case knowing the old values is at most a secondary task (i.e., only occasionally will a user care what the field used to be).
Design: Prominently mark the fields that have changed (see last paragraph) and show the old value as a tooltip with mouseover.
The above designs have the advantage that you can use the “normal” window intended for non-auditing purposes, cutting down on the number of windows users need to learn.
Task: Detail evaluation of how each field has changed, including perhaps a long history of multiple changes for each field, followed by occasionally correcting a value based on the history.
Design: On selection of a menu item, the window expands vertically to show old values in a read-only list below each new value. For long histories, such a list may need a scrollbar. For most alphanumeric values, it’s easier to scan vertically to see how things changed character by character than to scan horizontally. You should allow the user to edit values when in this mode and also select a value on the history list to revert the field. Saving pushes the now old values of edited fields onto the list. Tooltips may be used to provide secondary information (e.g., when each value in the history was entered and by whom).
Design: For “heavy” fields, like a large rich-text box, consider a display mode that uses strikethroughs and highlighting to show changes within the field, such as done by MS Word in Track Changes.
The above two designs still use the “normal” window, which minimizes learning, but modifies the window’s size and layout, requiring somewhat more learning and re-orientation than the first two designs.
Task: Find when and who changed specific fields. Here, the user already knows or suspects which fields have been changed and what the new values are, but now wants to know how they got that way.
Design: If the users generally needs to check only one field, then a menu item opens for the field that currently has focus a small window with a grid listing the history of values, who changed them, when they changed them, and any other auditing information (e.g., who approved it and when). If histories tend to be long, provide sorting and/or filtering. You can provide a command button that sets the current field value to one selected from the history grid. Note that this is different from the list using tooltips in that the user is primarily interested in figuring out who and when the field changed, not in what the field should be –it’s easier to scan through the timestamps, but harder to revert a value.
Design: If the user is likely to need to check and compare multiple fields in a window, provide a closeable history pane rather than a window. As the user tabs through the fields in the window, the pane updates instantly with each field’s history, complete with timestamps and usernames. A menu item can revert the field to a value selected in the pane. This is suitable for a user group for whom auditing is a fairly regular task, not an exception rare done.
The above two designs minimally disrupt the “normal” window, but require the user to learn an entirely new window or pane.
Task: Reconstruct the evolution of data objects through multiple updates of multiple fields. In this case, correcting values is not part of the task.
Design: Provide a general audit window for any arbitrary list of fields or objects, allowing the user to query/filter by fields, field values (e.g., to answer, “when was this ever X?”), windows, database tables, and, of course, timestamp range. In addition to supporting ad hoc query, you can allow the user to open the auditing window for all the fields shown in their current window. You can also provide an easy way to populate this table with fields the user regularly needs to audit or with fields that automation determines should be audited. The audit window shows a sortable grid listing the timestamp, data object (or table), field, old value and new value, and username. When sorted by timestamp (perhaps should be the default), the user can infer how changes influenced each other across fields (e.g., User A change X to 2, which probably led User B to change Y to 4). You may want to provide graphing options to help the user see correlations in changes. This is the most powerful auditing tool of the designs I’ve given, but it also requires the most training and skill to use.
For all the designs, it’s indeed a good idea to color-code recently changed fields to help the users spot what they are likely looking for (i.e., something different than the last time they looked). You may even want to have three or four gradations of recentness. I’d choose a bright color to suggest “newness,” but I’d avoid red which implies something wrong (not necessarily the case) or a required field. How about a sunny yellow “halo” around the field? Something like border will avoid issues with readability of the field. For accessibility reasons and better self-documentation, I would also include a redundant cue such as an alt-tagged icon (maybe a “sparkle”?) or simply the word “new” beside the field.
If each field contains fairly simple data then I might just have back and forward buttons so that you can toggle between previous and current view. In the current view (or perhaps both views) highlight the fields that have changed. The previous view should provide some visual cue that the fields are disabled (like greying them out). This gives you locality with respect to the change set (i.e. the user can quickly see what values changed) without too much visual clutter.
I'm lazy, so:
Turn the old data into text
Turn the new data into text
Use diff to show the differences
Educate users about how to interpret diff output