I am not sure if anyone has seen an issue where ReportCaster advanced parameter values disappeared after a server migration before. However, I thought I'd ask the WebFOCUS experts about this. Our WebFOCUS development (test) server was recently replaced and everything on it was migrated to a new server.

Initially, we had an issue where ReportCaster was not working. We got the message, 'The distribution server was started in console mode, additional configuration may be required to connect to the ReportCaster repository'. As our server team worked through the problem, we got to a point where we got an error message, 'Error connecting to the WebFOCUS Reporting Server EDASERVE: EDA SQL STATUS (-9)' when trying to run a .fex from ReportCaster. We later got a message, 'The Distribution Server cannot run the job(s) because of invalid mode.' I found some helpful information on this type of problem from a WebFOCUS forum and I believe our server team looked at an odin.cfg file and we were soon able to run reports from ReportCaster again (in development, production was never impacted).

However, we do have an unresolved issue where all of the ReportCaster advanced parameter values that we had set up (in development) no longer appear in our scheduled report tasks. This would be a huge problem in production, however we don't have very many ReportCaster tasks in development and this is not a big deal for us. However, I would like to understand what happened so this does not happen again and so that I can point our server team in the right direction. Any insights or information would be appreciated. Thanks.

Chris

This message has been edited. Last edited by: Kerry,

Did your BOTPARMS table data get migrated correcly?

Update: I had previously posted that all of our WebFOCUS ReportCaster scheduled tasks in our DEV test environment lost their advanced parameter data values after our new DEV server was built.

However, this was not correct. Most of the WebFOCUS ReportCaster scheduled tasks in our DEV environment lost their advanced parameter values when our new DEV box was built – and the effected scheduled tasks were those tasks that also existed (with the same schedule ID) in our QA test environment. We also had a few scheduled tasks in DEV that did not lose their advanced parameter values when the new DEV box was built – these were the tasks that only existed in our DEV environment.

I therefore believe that our ReportCaster issue was related to scheduled tasks with the same schedule ID that existed in our two different test environments. I had been testing the ReportCaster Change Management Interface a few months back and had copied ReportCaster schedules from one of our test environments to the other test environment to see if this could be done. I was able to run these ReportCaster schedules in both environments until one of the environments was rebuilt.