Worked most of the day on Friday - working on this report. I stated at 7 am and worked most of the day until 8:30 pm. I had a lunch break and went to the city party with my kids for a bit, but most of the day was spent on this report and logic. See elements of time # 4919 in the shop for more details. Lots of testing, rewriting, and some praying. This was pretty deep but somewhat developed into a series of smaller funnels and grouping and filtering to get to smaller and smaller data sets. Minimal trips to the database and then back and forth between memory objects to filter the data. It's not all the way done yet, and it has only been tested locally, but I feel that it has some potential, not just for the current report, but also for a future database feature called real in-line extensions.

The crux deals with a record set and then being able to filter that record set based off of numerous (unlimited) outside filters with somewhat randomly connected data points. The random data points, in this instance called sub inventory attributes, are user controlled fields. These custom fields point to custom tables that are not part of the main database tables. They basically hold the custom data and allow for the full structure to be reconstructed on the fly. We have future plans to use similar custom tables to hold data type specific values for all other areas of the database.

We have a thing called flex grid tie-ins and they now have 30 custom fields. Those fields may be named and used as needed. The main problem deals with a thing called a data type. The different data types are (generally speaking): text values, dates, times, numeric values, decimals, and on/off switches called toggles. We also have custom bulk object for storing JSON objects. Anyways, the data types allow for special things. The older flex grid tie-ins (all 30 of the custom fields) are strings and may hold all kinds of data. However, when being looked up and/or filtered, they are all treated as strings (simple text values). That makes it hard to do things like find something between this and that value, add things up, figure out max and mins, average, etc. A data type is required for that types of action. Anyways, lots of work was spent today on trying to work around those pieces and params. Good stuff.

The only other notes for this entry are some hints: joins, filters, and groups or grouping - doing these things over and over again, helped us get back to the requested and filtered data. Repeat the process as many times as needed. Keep narrowing the players.