Upgrading from 8.2 to 8.3 and testing out the new No Data Content functionality. Report looks in order if results are returned. The No Data message does not appear. However if we test the report (pass in parameters expecting no results), we are returned a blank page (pdf, html, excel output). Not even the header or footer appear on the page. And the No Data Content message does not appear as well.
We have very complex reports using Oracle SQL and in most cases the Header content is linked to a SQL statement to render output from the database as well as list the parameters passed in. The issue seems to be related to embedded data objects, i.e. we have a list object embedded within a table object. I've tried stripping out the extra layers with no success thus far.
In 8.2 we used style variables, i.e. RowNumber()=0 or RowNumber() is null to conditionally hide data objects in the body of the report. We've never used any conditions to hide or display the header or the footer and in 8.3 now this seems to be an issue.
This seemed like such a useful enhancement in 8.3 but we haven't gotten it working yet. Any thoughts or suggestions to try?
Thanks for reading this. I appreciate any advice.
Joe
We ran into this same problem when upgrading reports from 8.2 => 8.4. We reported it to Cognos as a bug -- Not sure if they've assigned a bug tracker id to it, but we got the impression it wasn't going to be fixed soon. (Obviously, if it exists in 8.3 and it has been carried forward to the next version, it's not a high priority.)
I'm sorry I don't have an answer at the moment on how to fix it, but I was planning to look into work arounds next week. I'll edit this post with any ideas I come up with.
UPDATE:
Not sure if this is an available feature of 8.3, but in 8.4 there is a new "No Data Contents" property for data containers (lists, blocks, etc.). Setting this value to yes creates two tabs at the top of the page, one for a page to be displayed if data is returned, and another for instances when no records are found. You can customize a message to be displayed using that second page. Pretty cool, actually, but buried in the documentation.
Hope that helps. If you still have problems, check out the Index topic "no data > specify what appears for a data container."
yea it appears that a blank pdf is returned... but in fact the cognos viewer bugs out at the second prompt page if there is no data. Headers and footers and items in which didnt need data to render ... as not showing up as well.
This existed in 8.2 and we were always able to do some sort of work around to get it to atleast show. Seems much more prevalent in 8.3 now.
Id like a solution on this as well! halp! >_<
Edit: seems a slight work around is to create a new report in 8.3 and copy each component starting with queries... then variables.. then objects on the page.. followed by page sets and master detail relationships. in that order for simplicity. Essentially recreating the report from scratch in 8.3 seems to fix the problem.
This works for about 90% of our reports.
Related
We are currently migrating our EDMS into SharePoint. As part of this workstream, I recently set up a SharePoint site with a Quick Part Label containing just the version number - as per the instructions here.
This worked fine in testing, now a few users have been added to the site and the migration works have begun. The option for "Label" within Quick Parts has simply dissapeared.
I tried some trouble shooting on Friday and found the following:
Recovering an old document from the recycle bin, still contain a correct version number label.
This label can be copy and pasted to a new document, and it correct applies the label quick part with the new documents version.
I set up a new test site and the Quick Part Label behaved exactly as expected, meaning the issue is within the Live SharePoint site itself.
I turned off labels and reset them. With no success.
I am opening in the app, the library has minor versions, check-in/check-out turned on (and currently approvals are turned off).
I also suspected that OneDrive sync might cause issues, but this again didn't seem to solve anything in the test site.
NB: this is also posted here, I will keep both threads up to date.
Screenshot showing label missing
Update 20/12/22
Since this morning I have now taken the following additional steps:
Added a new content type
Recreated the label for that content type
Change the content type of the document in the library, and the label
option now appears
This seems like a fix, but I am also curious as to limitations of
this method.
Limitations noticed so far: cannot edit SharePoint columns in the
details pane
Yesterday, the person in charge of adding content to our OrchardCMS website suddenly got this error when trying to access the Content section in the Dashboard and we can't add any new content any more.
I've imported a bacpac of the database in production and started locally debugging. When trying to access the Content an exception is thrown right here:
And, if we look in the database, the Orchard_Framework_ContentItemVersionRecord table contains a duplicated item with the same version Number, both are "latest version" and they both have the same ContentItemRecord_id.
My concern now is how should we fix this without causing any side effect somewhere else, since I don't fully understand how Orchard manages relations between items, parts, and versions.
Solution proposal:
It seems natural and obvious to manually update the "is latest version" of one of the items to false and increment the version number of the latest one.
Is this solution right or will I cause a side problem?
Have you experienced this before?
Do you know if this is caused by a wrong way of defining the model or something I can do to prevent this from happening again?
Quick answer: it is probably due to double clicking the publish button... Small tip and hack: hide publish button on click...
I remember that happened to me once before, it was ugly situation and a lot of debugging had to be done to find the cause.
The only fix I could find back then was to alter/edit/fix the db data manually.
I must ask
did that error happen once or does it happen all the time?
Xpage (listPostits.xsp) has a "View" container control, where one of the column is set "show values in this column as links".
Now, here comes "Strange behaviour".
When i work with this application on my own (developer) PC (Win XP, Chrome or IE), the Domino generate the link, which can't be really processed:
/servername/db/postit/postit.nsf/listPostits.xsp/onePostit.xsp?documentId=many_numbers&action=editDocument
Namely, the Bold-marked portion shouldn't be there ! This portion is the name of the XPage, where the View control is in.
When i work with the application from other PC (Mac, Firefox) then i get the correct link (the same as above but without the XPage name inbetween):
/servername/db/postit/postit.nsf/onePostit.xsp?documentId=many_numbers&action=editDocument
update: let us leave for the moment the differencies in generated links between two machines. The first question is - why the extra portion is inserted into automatically generated link?
After playing around i think i might have found the reason for this strange behaviour. Namely, the "Substitution" Rules on the server side. One of them is to substitute "*/postit/all" with "/db/postit/postit.nsf/listPostits.xsp"
If i switch it off, then the Links are generated properly. Still, it's pretty strange to me that these settings influence the way Domino generates the links. I thought it works on the fly with them and those settings have nothing to do with the way how Links are generated inside the application.
So, the help now is needed regarding Web Site Rule Topic, but for that, i guess, i have to create another topic. But in case somebody has some good Info on this, please share it with me. I'm a bit confused at the moment :)
Final Update: Spent some more hours of testing and the results confirmed the initial idea.
If i open the page with the standart URL, i.e.
http://servername/db/postit/postit.nsf/listPostits.xsp then everything is fine, links are generated properly. When i however open the same page with short URL http://servername/postit/all , then server adds the substitute URL (db/postit/postit.nsf/listPostits.xsp) to every single link he generates automatically to be used as the link to open/edit the underlying document.
Is it bug or feature ? Don't know.
As a workaround (because i want to keep simple URL's for the application) i have to manually generate links.
Whenever I save or create a node of a certain user-defined type, I am back in the edit window instead of switching to the first tab labeled view. All my fields (body, title etc. are as they were and no message appears, neither directly on the page nor in the watchdog database log. The validation is working, though, because I see those 'required' messages as soon as I try to save without Title for example.
The strange thing is that when I create a new content type, or use the predefined story and page types, I can edit and create nodes. In the latter case, Drupal answers with an 302 redirect, whereas with the proplematic content types, only a 200 HTTP status is returned.
The issue doesn't seem to be related to either JavaScript (on or off, no difference), Browser (tried Chrome and Firefox) or WYSIWYG (used input formats with and without).
I'm using Drupal 6.22 and the CCK. I have about 7 content types, some of them with fields. I am not using Rules, but a multitude of modules, all of which are up-to-date. I will post a list if this issue can't be solved otherwise.
I have spend the last hours trying to figure this out, both by looking at my installation (settings, database) and by searching Google & Co.
Any ideas?
The situation appeared because Drupal translated both the Upload and the Save button to one word, Speichern. The FileField issue tracker contains the corresponding thread: http://drupal.org/node/684426
The ImageField and Locale modules, along with a language such as German or Finnish were partly responsible for the trouble.
Situation:
A custom "Master Document" content type inherits from Document
The "Master Document" content type has five additional choice fields
There are five custom "Document Template" content types that inherit from the "Master Document" content type
Each of the "Document Template" content types uses a different Word document template (.dot) file
Each of the "Document Template" content types have been added to a document library
Problem:
I click on a document in the library
Document opens up in Word 2003 for me to edit
I make some changes and save
A box pops up called "Web File Properties". The window contains all of my custom metadata properties and the ContentType field. The ContentType field is set correctly to the current content type. The other fields are reset to their default values. This same window can apparently be opened by going to File -> Properties
This window by itself would be fine except for two reasons:
It includes the ContentType column
All of my custom metadata properties are visible but are reset to their default values instead of whatever values were previously selected. This means, every time the user wants to save the document, they have to remember what properties were tagged and set them back.
Question:
Can I disable this Web File Properties box?
If no... can I get the fields that show up to be populated to their correct values?
If no... is there a way to disable my fields from displaying in this window?
If no... is this a SharePoint page that I can modify?
***Edit with some more information***
It looks like this only happens in Office 2003 and looks like it affects Choice fields. If I create the same column as a Lookup field, it seems to work.
Edit again
Looks like if the lookup field is a multi-select field then it will not show up in the Web File Properties box at all (single select lookups still work).
edit 10/14/2009
Link to the KB Article mentioned below by Brenda:
http://support.microsoft.com/kb/971500/
This is more of a workaround rather than an answer but I figured I might as well put it here in case it helps someone else.
It seems as if these issues with the Web File Properties box is specific to Office 2003. The issues I reported above seem to be fixed in Office 2007.
If you want to get it working in 2003 and you have choice/lookup fields in your Document content type, here is the summary:
Single select Choice fields DO NOT work
Multi select Choice fields DO work
Single select Lookup fields DO work
Multi select Lookup fields DO NOT work
FYI - I want to CORRECT my previous post. The fix DID FIX my problem after I deleted my internet cache. Works PERFECT now. Here is the KB you need: KB971500 I can email you the fix if you can't find it. The notes in the document do not describe the problem exactly as I would have, but it was the fix for my case.
bhartson#lbrealty.com
We have the EXACT problem. I've opened a case with Microsoft back in February and they were able to finally duplicate my problem.
I have been kept informed and told that my fix would be available with the JUNE cumulative upates. I just received a specific hotfix from my Microsoft rep and applied it and it still did NOT fix my problem. I am hoping he gave me the wrong one and has the real one to send me.
Thanks for your post. I'm may try some of your suggestions above but I just want Microsoft to fix this. We can't upgrade to Office2007!
Thanks.
man, this was really killing me, I spent an entire day recreating document libraries and all sorts of content-types and variations of my excel template before I figured this was a bug... At least MS has a little hotfix request thing now... they're going to send it to me I guess :\
I didn't test this in excel/office 2003 and really botched a presentation of our little workflow... embarassing... always test with the app & environment people are going to use!!!
thanks for the KB article number