Danny and Steve were talking about switching labels over to QR codes and even getting rid of our existing simple barcode stuff (on adilas standard labels). Barcodes work great until the barcode gets too big, then it breaks down because the barcode no longer is scannable (long barcode in a tiny space). QR codes have such a bigger range of characters and number of characters that they can show. That is where we want to head. We can already do that (QR codes), we just need to make more of an effort to make that the new default option.

Wayne presented next and we covered his changes that he will be implementing dealing with corp-wide settings. We currently have them all saved in a couple of corporation level tables. The tables are getting really big and are starting to cause problems due to how big they are (number of columns). The new solution will allow the settings to be held in data type specific tables based on the corporation id number, the setting name, and the setting value. Pretty simple. We will have new settings tables for strings, big strings, integers, decimals, and dates. That should cover most of the corp-wide settings.

Alan joined and Wayne was showing Alan and I some of the new code, objects, functions, and logic to deal with these new settings tables. We went over flow, validation, options, setting groups, global settings, etc. Lots of topics around the new changes and upcoming changes for the corp-wide settings. It is looking good (at least in concept).

We got into optimization strategy stuff. Taking the next logical steps and moving forward. We also talked about static vs dynamic and how static (set number of settings) placeholders actually take up more space than dynamic (only what you need) settings. We will provide defaults for each, but only store what is needed. We will end up using the dummy corporation as the default and then only store settings that are different per corp. Much more efficient on the storage side.