When the user pressed the button, the code procedure created records in the temporary table that fit the defined date range.
I placed a button on the screen with along with a beginning and ending date for the report. The temporary table, not the original table, would form my “line items” detail on the report. I decided to try creating an invisible temporary table, and, based on the user’s own entered date range, and populate that table each time the report was run. But which date range? And, could I expect novice users to go into the report layout screen and apply a filter there? As a programmer, I can apply date filters manually to narrow the records to a date range. I needed to find a way to narrow them down. I needed a subset of those records as the “line items” in my report because a report based on the entire table would be many pages long too overwhelming to be useful.
Upon implementation of my database there are going to be hundreds of records in the table. Here’s what I mean: I had a report based on records in a table. They aren’t a part of the database architecture at all. These are tables that hold records only for a short period of time while you need them for a specific purpose. What I stumbled upon in my effort to solve a couple of puzzling programming problems is quite simple to put into place, requires no fancy programming to learn and can be used by any Ninox beginner. This week I discovered a very simple solution to a couple of challenges that initially had me stumped.
0 kommentar(er)
