Working with Bryan to cover some options for a client. The client wants to be able to record more information on a per PO basis. We talked about 4 different options. 1. Use flex grid tie-ins and black box code to get the job done. 2. Add more flex grid tie-in fields. Currently there are 15 and there has been some talk about extending that to 30 (double). 3. Use a custom form to collect the data, a custom action page to push the data where it needs to go, and build a custom black box database table specific to the task at hand. 4. Look into and build out the real in-line database extensions (be able to expand the native database tables as needed based on a per corporation basis).

We spent quite a bit of time discussing each option. Without trying, we ended up spending more time talking about the option 4, real in-line database extensions. See the link below for more notes about this option. We already have a few small in-roads to this solution, it just needs to go out the next level. As part of that conversation, we talked about a new table to help control the custom field names and assignments. This would be a new table that would allow us to setup the new fields, what to call them, what data types they were, and where the data would be stored. Along with this, we also briefly talked about the existing custom dates, custom numeric, custom text, and custom json tables. Currently, we already have some logic in place on sub inventory and sub attributes as well as parent attributes. Both sections use the custom tables to hold the data.

I warned Bryan that even though these new dynamic features sound awesome, there are some major challenges. Including searching, dynamic show/hide, requirements, sorting, defaults, custom instructions/directions, ect. In a way, it almost sounds like another project that is tied to a database table called db_field_settings. That table allows for normal or default database fields to be named, show/hide, sorted, defaults, maxes, mins, etc. They both have a similar flavor. The main difference is one controls tables that already exists and have fixed columns or field names and the other is kinda managing vaporware or fields that are wanted and needed but only exist in the real in-line extensions. Interesting.

https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=database%20extensions%2Breal%20in%2Dline