Reporting in WCS 6.0.132

[Max.Caines]

I recently upgraded from WCS 5.2 to 6.0. I have a number of Client Count reports set up, which are run weekly to generate PDF graphs of usage on all APs in each building. Since the conversion, all of them fail with the message "Failed to run report". I've tried deleting and re-defining them, but get the same result. Running them manually makes no difference. Has anyone seen anything similar? Is there anything I can do, or is reporting just broken in 6.0? The message is singularly unhelpful

Regards

Max Caines

University of Wolverhampton

[Lucien Avramov]

I have client count to work in my lab on 6.0 in PDF.

Can you try to login as root to wcs and use the root virtual domain?

Would need the wcs logs with trace enabled for further analysis.

[Max.Caines]

Hi

Thanks for your help. All my reports are run as root in the root domain anyway. What I can say is that the problem only occurs with reports that have a schedule. I have a particular report which gives 802.11g usage for all APs in one building over the last 7 days, presented as a PDF. If I set that up without a schedule and run it, it's fine, and I get the results on screem. If I set up the same report with a schedule (single-instance or recurring) it fails, and if I then try to run it by clicking the Run icon on the saved report, it fails again. I've put a copy of the log files with trace on at http://ccug.wlv.ac.uk/its/WCS.zip (it's too big to attach). Near the end there should be two runs, one of the job "Test" at about 8.55am, and one of "Test2" (scheduled) at 9.00am. If you can shed any light on this, I'd be very grateful

Regards

Max

[Lucien Avramov]

I'm not able to reproduce your issue in my lab with client count, even my scheduled reports do work.

I do not see any bug yet on this, let me investigate this further and get back to you.

Can you please also post screenshots of the working and non working environment (when you schedule the report and when you run it now).

The error in your logs is:

8/05/09 08:59:09.586 TRACE[com.aes] [42] [TEMP_TITLE_1249459149270:run] THROW

net.sf.jasperreports.engine.design.JRValidationException: Report design not valid :

1. Field not found : BaseAp.lradName

2. Field not found : BaseAp.macAddress

3. Field not found : BaseAp.lradName

4. Field not found : BaseAp.macAddress

It seems not to find the database entries when the report is scheduled.

You are still talking about the client count report, correct?

[Max.Caines]

OK, I'm enclosing some screenshots in a ZIP file. The first two are of a saved scheduled job, and what happens when I do "Run Now" on it. The next two are the same job content, but not saved, just run immediately. And yes, this is all client count reports. Probably worth mentioning that if I do a "Controller" report rather than an "AP by Floor Area" report, it works every time. I've posted an example as WCSReport5.jpg.

Thanks for your help

Max

[Lucien Avramov]

Can you provide the upgrade path taken for the WCS? How did you get to WCS 6.0 ? From which version(s)?

Get me following output by going to "https://x.x.x/webacs/dbQueryAction.do" (where x.x.x.x is the ip of WCS server) and run the command "select * from

wcsdb.modb.reportsettings where titlename='Test'" (where Test, i

understood, is the name of the report failing the scheduled run.

[Max.Caines]

We went from 5.2.130 to 6.0.132. I've run the query, and the results are attached. I've saved them as plain text; they're too wide for a screenshot.

[Lucien Avramov]

Have you used a beta version or earlier pre release version?

You have an issue that is related some how to entries that were in beta codes of WCS.

A few things to try, first make a backup of your db.

Then, go on the CLI, bin folder of WCS and after run:

1.StopWCS

2.dbamin checkschema

3.StartWCS

See if this helps.

I dont want to push you for opening a TAC case and would like to avoid it, but if you are concerned about keeping the same db and not loose any data, we need a TAC case to be opened. That will involve that you upload me your database so we can try to fix this manually.

If you dont care about the DB and you are ok to rebuild it then from the CLI

1. StopWCS

2. dbadmin reinitdb

3. StartWCS

Reconfigure your WCS, the issue will be gone.

If you decide that you can not loose the db and the previous steps did not help, open a TAC SR between now and the next couple of hours and ask for lavramov, I can help you out.

[Max.Caines]

No, we've only ever used released code. I've run the database schema check, and tried another scheduled job, but they are still failing. I can't open a TAC case myself, but I'll get our dealer (Logicalis UK) to do so for me. I'll ask them to direct it to you. Thanks

[Max.Caines]

The TAC case isn't open yet, because our dealer needs to get a serial number for the WCS. In the meantime something I ought to mention is that because we have both 1010 APs and 1142s, we are running a mixture of code on the 2 elements of our WiSM: 6.0.182 on one half and 4.2.176 on the other. By the way, the schema check I did this morning did make one difference: although scheduled reports still fail, I can now run them online after they've failed (by clicking the "Run Now" icon), whereas before they used to fail then too. I've repeated the DB query you asked for before, and attached the results in case they help at all.

[Lucien Avramov]

Did not get much more from the output attached.

There is no serial number on WCS, it's just a software.

It's ok to have the 2 controllers in the WiSM to be on different codes, that should not be an issue.

[Lucien Avramov]

What happens if you create a NEW report in WCS 6.0 and schedule it? Does it give you the same error?

The last db output seems fine.

[Max.Caines]

It's a new report that I was trying. The scheduled job fails (no idea why), but stays on the "saved jobs" list. If I click its "Run Now" icon, it then runs OK. By the way, the TAC case is SR 612185681, but it's being handled by Amjed Dweik (adweik@cisco.com). We were told we couldn't control who it got passed to.

[Lucien Avramov]

Thanks for reporting this, I created a new bug for this issue : CSCtb51301

It will be fixed in the next 6.0 maintenance release