posts

You hid some rows in your JasperReports report and the total at the bottom still counts them.

Two ways to make a row disappear, and they differ in exactly this. A band-level printWhenExpression suppresses the render: the record is still read, still counted, still summed. A filterExpression removes the record before any of that happens.

Fix: choose by what you want the aggregates to say. Hidden but counted is printWhenExpression. Gone is filterExpression.

Four rows, one dropped each way, and what each total printed: https://robcotek.com/go/li-2026-10-15

Every reporting team has a person who "just knows" to re-run step 3 when the totals look off, or to wait ten minutes after the load before refreshing. That is not a process. It is a single point of failure with a badge.

The knowledge is real and it works, which is exactly why it never gets written down. Nothing is broken enough to force the question. Then that person takes a week off, and the Monday numbers go out wrong, and the fix everyone needed was in a head that was at the beach.

I've been that person, and I've inherited from that person. Neither side is fun.

If the fix is not written down where the next person will trip over it, it does not exist. A comment at the top of the job. A line in the runbook. A check that fails loudly instead of a habit that quietly compensates.

Write it where the failure happens, not in a wiki nobody opens.

Your JasperReports parameter default works from the designer and not from your application.

The rule is one sentence: a default fires only when the key is absent from the parameter map. A key that is present with a null value is a supplied null, and the null wins. Most application code puts every key in the map, null or not, so the default never gets a chance.

Fix: never pass null to mean "use the default". Leave the key out. And write the default as an expression that yields the declared type, because there is no conversion from a String.

The three cases measured side by side: https://robcotek.com/go/li-2026-10-08

Ask three teams what "active customer" means and you get three answers. Ask the database and you get a fourth, because the real definition is a WHERE clause somebody wrote in 2021 and nobody has read since.

Every org has a glossary somewhere. It is aspirational. The definition that actually produces the number on the board deck is the filter, the join and the default that the report runs through, and those were written under deadline by whoever had the ticket.

I've reconciled enough of these to know the gap is never malicious. The glossary says one thing, the code does another, and the report has been "right" for years because nobody compared them.

The glossary is what people say. The join is what the number does.

If a definition matters, put it in one place the report reads from, and make the glossary point at that. Two sources of truth is one more than you can keep honest.

The prompt shows the right labels. The user picks one. The report returns zero rows. No error.

Cognos prompt controls carry two values per entry: the display value the user sees and the use value that actually goes into the parameter. If the use value is a different column from the one the filter compares against, the parameter carries "West" and the filter is looking for "W".

Fix: make the control's use value the same column the filter consumes. Friendly label as the display value, the code as the use value, and the filter on the code.

Symptom, mechanism and the exact wiring, run on a live instance: https://robcotek.com/go/li-2026-10-01

Half the scheduled reports in any org go to an inbox that deletes them unread. They still run every morning. They still break when a source changes. Someone still gets paged to fix them.

The person who asked for it changed roles in 2022. The distribution list has four addresses, two of which bounce. Nobody has opened the attachment this year, and nobody has cancelled it either, because cancelling feels like a decision and letting it run feels like nothing.

A report with no reader is not free. It is maintenance with no customer, and it competes for the same hours as the reports people actually depend on.

I've done the audit a few times. The number is always higher than anyone guesses, and the pushback is always "someone might need it."

Turn it off and wait. If nobody calls in a month, you had your answer. If somebody does, you found a real reader, and now they are on the list.

The most expensive report error is not the one that crashes. It is the one that keeps running and quietly returns a different number.

A crash gets a ticket in an hour. A silent change gets discovered in a board deck three weeks later, by the one person who remembered what it said last quarter. Now every number on the page is suspect, not just that one.

I've traced enough of these to know the cause is almost never dramatic. Someone added a status code. A source table gained a column with a default. A filter that used to match everything started matching most things.

Nobody files a ticket for a report that still loads.

If a number can change without anyone being told, it will, and you will find out from the audience. Compare this run to the last one before anyone else sees it. Boring, cheap, and the only alarm that catches this class.

The dangerous AI answer is not the one that fails. It is the one that looks right, reads with total confidence, pastes cleanly into your report or your code, and does nothing. No error. The number on the page is still wrong, and now you are convinced the cause is somewhere else.

I put hundreds of real reporting questions to current chat models and then ran what came back, claim by claim, on live systems. The pattern is consistent enough to describe: it learned from the internet, where the most repeated answer wins. It read the docs for a version you do not run. It fills gaps with plausible shapes that tools accept quietly. It never ran anything. And it agrees with your framing.

The numbers from one library: of 113 JasperReports questions that never got an accepted answer, 82 came back with at least one wrong claim, and 56 had a claim that fails without saying so. Questions that already had an accepted answer: 2 of 16.

Six checks before you paste, and where the vetted answers are. No paywall, no email: https://robcotek.com/articles/why-ai-gets-it-wrong/?utm_source=linkedin&utm_medium=post&utm_campaign=why-ai-gets-it-wrong

Every reporting org has a scheduled job nobody remembers writing. It runs at 4 AM. It produces a file the close depends on. The person who wrote it left in 2019.

The temporary scheduled job is the most permanent kind of scheduled job. Documented as "TEMP, WILL FIX LATER" in a comment from a previous job title. Nobody wants to touch it because nobody knows what breaks if they do.

I've inherited a few. Every one was load-bearing. None of them looked it from the outside.

If a four-year-old script is producing critical numbers, that's not a script. It's infrastructure without a maintainer.

The fastest way to find these jobs is to stop them and wait for somebody to call. The right way is to find them before that.

If leadership doesn't believe the number, the system is broken regardless of architecture.

A reporting system's actual job is producing trust. The reports are the artifact. Trust is the product.

I've watched beautifully engineered platforms get ignored because the first three numbers anyone checked didn't match what they thought they should be. After that it doesn't matter how good the pipeline is. The damage is done, and nobody wants to be the one who used the wrong dashboard in the board deck.

Most teams optimize for the artifact. Cleaner charts, faster refreshes, prettier tooltips. And wonder why nobody uses it.

If the number doesn't get believed, the system doesn't get used. The whole job is earning that.

You don't really know what your data is doing until you try to move it.

Every system migration is also an undocumented-business-rule audit. The "simple" port becomes a three-month archaeology project, because half the logic was living in a join nobody remembered writing and a default value nobody remembered setting.

I've been through enough migrations to know the timeline always doubles, and the reason is always the same. The old system was doing more than anyone documented. The new system has to do all of it, or somebody's number breaks.

If a migration finishes on the original schedule, the migration didn't find everything. It just shipped the not-finding-it problem forward.

Move slowly. The system will tell you what it actually does.

Roll out the dashboard. Watch the exec export it to Excel within a week.

It's not that they don't trust the dashboard. They don't trust anything they can't recompute.

I've watched it happen at every reporting rollout I've been involved in. The first thing a serious exec does with a new dashboard is download the underlying data and put it in their own model. Not because the dashboard is wrong. Because they need to know they could find out if it was.

If the system doesn't let people verify the number, they'll go find one that does. Usually a spreadsheet.

The export button isn't a failure mode. It's a signal that trust hasn't been earned yet.

Every reporting org has a personal workspace report nobody else can see. The CEO checks it every morning.

It started as a one-off pull. Then a weekly habit. Now leadership budgets off it, and nobody can audit it because it isn't in the catalog. It's in someone's personal space, behind their login, with no review.

I've inherited a few of these. Migrating one is always harder than rebuilding it from scratch, because nobody documented what makes the number land where it lands.

The "scratch" workspace report is the most permanent kind of report there is. Personal because it was personal once. Permanent because everyone got used to it.

Build the workspace report like it's going to outlive the person who built it. Because it will.

Accurate yesterday beats wrong right now.

Real-time is what gets sold. Trustworthy and on-time is what actually runs the business.

I've sat through plenty of demos where the headline feature was streaming dashboards. Most operations don't need a streaming pipeline. They need a number they can defend in a meeting and recompute next quarter.

The cost of "real-time" isn't just the engineering. It's the surface area of things that can be wrong in a way nobody catches until the exec already saw it.

Pick the latency the business actually needs. Then build for accuracy, not speed.

If three people disagree on what "active customer" means, no chart is going to fix that.

The expensive part of reporting isn't the visualization layer. It's the agreement on what the words mean.

I've watched projects spend six months picking a tool, three months wiring up data, and then discover at the demo that ops, finance, and sales each had a different definition of the central metric. Now the dashboard is right. And wrong. Three different ways at once.

Definitions aren't documentation work. They're the actual product. The chart is just where the agreement gets displayed.

Get the words right first. The pixels are the easy part.

Every BI tool I've inherited had 400 reports. Twelve of them were in use.

The rest were built for one meeting, one exec, one quarter. Nobody had the authority to delete them. Nobody had the interest. So they sat there, getting refreshed, occasionally showing up in a search, occasionally confusing somebody who picked the wrong one.

I spent years inside reporting orgs cataloguing what was actually being used. The active set is always smaller than anyone expects.

The dashboards that matter announce themselves. They get linked in chat. They get bookmarked. They get cited in meetings. The other 388 are landfill.

Build slower. Delete faster.

The reporting system that runs on one person's willpower isn't a reporting system. It's a hostage situation with good intentions.

Every reporting org has one. The person who comes in early during close. Who knows which tab to refresh first. Who can answer the question before anyone finishes asking it.

I've been that person. I've also had to replace one. Neither is a place you want to be.

The hero gets praised in the all-hands. The hero also can't take a vacation without somebody texting them about a number. That's not a compliment. That's a system that depends on one person never being unavailable.

The right reward isn't a shout-out. It's making the hero unnecessary.

Most reporting problems come down to one question: where does this number live?

I've watched it derail meetings, projects, and entire close cycles. If the answer is "the report itself," that's the bug. The number exists where it gets shown, with no single source. Every consumer derives their own version because there isn't one to share.

A real reporting system has one true place for every number. The reports read from it. The dashboards read from it. The exports read from it. When somebody asks "is this right," the answer points to one place, not five.

It sounds basic. It's the first thing most operations get wrong, and the last thing they fix.

The number lives somewhere. Make sure it's only one somewhere.

If month-end close is a fire drill, the reporting system isn't a system.

I've sat through enough of them. Three days of recompiling, recoding, re-explaining. Somebody finds last month's numbers don't match this month's. Somebody else discovers a tab got overwritten. The CFO asks the same question the controller answered yesterday.

That's not reporting. That's an annual tradition that happens twelve times a year.

A real system makes month-end a print job. The numbers are already right. The work is just packaging them.

If the same people answer the same questions every month, that's not diligence. It's a missing feature.

Excel is not the enemy.

I spent a decade managing reporting at enterprise scale, and I still use Excel daily. For one analyst, one recurring report, or a quick model nobody else will touch, it's exactly the right tool. Fast, flexible, everyone already knows it.

It becomes the problem when it leaves that lane. When five people maintain "the same" workbook on five different laptops. When a number in one tab drives a decision and nobody can trace where it came from. When "fix Excel" is in the job description.

The tool isn't broken. The boundary around it is.

Use Excel for what it's good at. Stop asking it to do the job of a database, an audit trail, and an entire reporting org.

The best reporting system I ever built was the one nobody called me about.

Reports ran on time. Numbers matched. Executives found what they needed without asking. When I went on vacation, nothing caught fire.

That's the whole bar. Not dashboards. Not real-time. Not AI-powered. Just a system that keeps running when the person who built it isn't around.

If the operation needs the builder in the room, the builder built a job, not a system.

Every tool I already use shipped an AI feature this year.

Some of it is useful. Most of it is the same shoebox with a chatbot stapled to the lid.

A pile of mismatched data doesn't become a system because you can ask it questions in English now. It just answers in English. The wrong numbers come back faster and with better grammar.

AI is great at working with information that's already organized. It's terrible at organizing it for you. That part is still the work.

The shoebox didn't get smarter. It just got a co-pilot.

Three people. One question. Three different answers.

I've been in that meeting more times than I can count. Someone asks for last quarter's number, three departments pull their own version, and now the meeting is about the spreadsheet instead of the business.

Nobody is lying. Everyone is right inside their own file.

A reporting system isn't a tool. It's an agreement about which number is the number. The tool is just where the agreement gets written down.

If three people can produce three answers, the problem isn't the data. It's the absence of a system.

The difference between a shoebox and a filing system isn't the size of your business.

It's whether you can find what you need in under two minutes without calling someone who might remember where they put it.

I built systems at enterprise scale that answered that question. The same principles apply whether you're running a hospitality empire or a three-person operation.

The tools are actually cheaper and easier now than they've ever been.

The hard part was never the technology. It was admitting the shoebox wasn't working.

Every business has a shoebox. Most don't know it until they need something that's in it.

Tax time. An audit. A new hire who needs the history. A decision that needs last year's numbers.

That's when you find out your filing system was actually just a pile with good intentions.

I've watched it happen at enterprise scale. The chaos is the same whether the shoebox is a server room or a kitchen drawer.

Good intentions make terrible filing systems.

Shoebox is not a filing system.

I spent a decade managing reporting inside a major hospitality operation. We had servers, shared drives, databases, and a team of analysts.

We still had a shoebox problem.

Different container, same issue. Critical information living in the wrong place, in the wrong format, owned by the wrong person.

The scale changes. The box just gets a better label on it.

I've watched what happens when the person who owns the reports leaves.

It doesn't matter if it's a resignation, a promotion, or an acquisition that reshuffles the whole org. If your reporting lives in one person's head and their laptop, you don't have a reporting system.

You have a dependency.

I spent years inside operations making sure that when I walked out the door, the systems kept running. Most businesses never think about that until it's too late.

Congratulations. Your reporting system's name is Dave.

When I first started building reporting systems, I went looking for the right tool to replace Excel for complex business operations.

There are a dozen solid options. Each one built for a slightly different use case. Four hours of research later I understood why most people just stay with Excel.

That's not a tool problem. That's a selection and configuration problem.

The right answer depends on the data, the workflow, and what specifically breaks. The tools exist. Picking the one that fits a given business, and making it actually work, is the hard part.

The right tool is out there. It's just buried under eleven browser tabs and a free trial nobody remembered to cancel.

Excel is the most successful prototype that never got replaced.

Somebody built it on a Tuesday to solve a real problem. It worked. It kept working. Five years later it's still load-bearing, still undocumented, and still the thing the business actually runs on.

Every "we'll replace it next quarter" plan loses to the version that already runs.

Most businesses don't have a data problem.

They have a spreadsheet problem pretending to be a data problem.

I know because I've lived on both sides of it. A decade managing reporting inside a major hospitality operation taught me the difference.

A data problem means your information is wrong. A spreadsheet problem means your information is right: ten by ten or in ten different files, maintained by ten different people, 10 different ways, none of whom know the others exist.

One is a data quality issue. The other is a very organized shoebo… infrastructure problem.