I get this error every now and then when I push a button in a Form to run a report on a view that bases its where clause on variables in a package (think of usernames, dates etc), even though in TOAD all my views and packages are valid, and running the report from the builder works just fine too.
Usually trying again compiles the package and makes it work, but not this time. After trying all sort of things, restarting the reports server did the trick. No idea why though, the reports server makes a new connection for every report, so it’s not pooling that causes this.
Archive for March, 2006
Existing state of … has been invalidated
Monday, March 27th, 2006Put .; in front of your classpath stupid
Thursday, March 23rd, 2006I need to remember this……
Don’t save your reports as JSP just because it’s the default
Wednesday, March 15th, 2006Personal experience learned me that reports saved as JSP files do not contain all the information the binary RDF would have, and thus might give you different results when run.
So unless you have a really good reason for saving your reports as JSP files, DON’T. Use the binary RDF files instead…..
Example:
I built a report that was outputting XML, and the query I built had uppercase columns and I changed the tagnames in the report to lowercase. This information is lost when the report is saved as a JSP file, but preserved in the binary. This particular case has an obvious workaround (change the query, or stop bothering, XML is case insensitive), but I can imagine other (more serious) examples exist.
Reports server does not show same results as Reports Builder preview
Tuesday, March 14th, 2006Whenever you get this, chances are you made a mistake. Check the following things:
- Are you connecting to the same database?
- Are you using the same user to connect?
- Are you using the same report?
and last but not least:
- Are you passing the same values to the same parameters?
I have been staring at an empty report generated with the reports webserver for 1.5 hours before I realized I misspelled the parameter name in the url.
Maybe Reports should warn users when they are trying to pass values to unknown parameters…… Or should I pay more attention to what I am doing?