Q: What is this about?
A: When using the dynamic syntax (aka $[$item.col.type]) there have over the lifetime of B1 Usability Package development snuck in a few inconsistencies in how the dynamic syntax gives back string-based values to the individual feature... So in some features example, BP CardCode on BP Master Data (aka $[$5.0.0]) gives the CardCode without 'pings' (Example: C20000) while in other cases it gives the string back in SQL-ready format with 'pings' (Example: 'C20000'). This FAQ will try to explain why, why we do not fix it and how to navigate this inconsistency most efficiently.
Q: Who did this happen?
A: The history behind it is that when B1UP was very new and introduced the use of Dynamic Syntax (Universal Functions - SQL Reports was the first) we did it just like SAP does it (with 'pings'), which worked well as the dynamic syntax was expected to only be used as part of SQL sentences... So perfect with automatic pings on strings.
But as the product grew, we realized that dynamic syntax could be used for so much more in the product... It made sense to be able to use it in places like subject and body fields of emails and such places where the syntax was not part of a SQL sentence... And in such cases, the pings were not something people wanted as it was human-readable text.
So we knew we needed to change, and decided that all new features (created after roughly 2010, should not automatically add pings to allow full flexibility...
The drawback of this cause was that the syntax in older features adds 'pings', while everything newer does not.
Q: Why don't you just fix it and make it consistent (aka why is this not fixed)?
A: If we had a time machine today, I think we should properly have taken the hard decision and had let it be a breaking change back then (so everywhere you needed to add the pings yourself), but back then we did not dare break backward compatibility.
So ever since then, we have on and off when cases like this come up or we hit it ourselves when working toiled with ideas off n how to "fix this"
| Fix | Why it is properly not a good idea :-( |
| 1. We could break backward compatibility | ...But we have so so many customers now that it would be a big mess |
| 2. We could have only new databases use consistent no-ping keywords | ...But that would make it even harder to understand as old databases are out the by the thousands |
| 3. We could document all places that use old style and new style in a document | ...But the fear is that people will not read it anyway (PS: if you are reading this then Thank you as such documentation at the bottom of this article :-)) |
| 4. We could try and do an auto-convert of all existing configs out there is a major release | ...But due to the highly dynamic nature of B1UP and its history of trying something similar, it is bound to fail at some level |
| 5. We could inline document each field if that field uses the old or new syntax | ...But we would need to plaster all configs with small hints like this as almost all fields in the system accepts a dynamic syntax |
| 6. We could create a brand new syntax replacing to old | ...But fear that people would just be confused as they are just too familiar with $[$item.col.type] |
|
7. Should we make 2.0 versions of all features that use old-style syntax that does not add pings |
...But will not really "fix this", only confuse... |
| 8. Build a time Machine | ...But Time machines still don't exists ;-) |
So as you can see above it is not a lack of things we have tried to think of to fix it, but that all the ideas kinda suck :-(
Q: So what are you doing if you do not like the above fixes?
A: The best "solution" right now is to be better at error messages, so when people make this 'mistake' (Including me, I made this mistake at least 5 times this year already), we want the error message back to be the best possible telling when a SQL failed, what the SQL we executed was instead of just the error message... That way the issue still happens (sucks), but at least it is easy to understand and fix (...ahh the pings are missing...)... While that help in many cases, it is not in every single case though...
Here is an example of such a fix:
Misconfiguration
Error result of misconfiguration prior to B1UP 2022.08
Error result of misconfiguration on B1UP 2022.08 and higher
Q: What other options are there for easy debugging of such issues?
A: The B1UP Debug Console is a really handy tool to spot these issues... Here is an example of how to use it for this very kind of debugging.
Q: Can you describe in more detail where the inconsistencies are?
A: Here is a list of places that add pings and places that don't (if you find a place not mentioned here please let us know)
Places that add pings automatically
| Feature | Module |
| SQL: syntax |
Universal Function – Message |
| SQL: syntax | Universal Function – Create Activity |
| SQL: syntax | Universal Function – External Launcher |
| SQL: syntax | Universal Function – Internal Message |
| Body, Line and Marked as Handled SQL | Universal Functions – File Exporter |
| SQL Condition | Universal Function – Line Loop |
| SQL() and SQL: syntax | Universal Function – Macro |
| SQL field | Universal Functions – SQL Report |
| SQL in SQL Variables | Universal functions – SQL Report |
| SQL: Syntax |
Universal Function – UDT Handler |
| SQL Condition | B1 Validation System |
| SQL in Conditional Controlled Menu-items | Right-Click Menu Creator |
Places that do not add pings automatically
| Feature | Module |
| SQL: syntax |
Universal Function – Crystal Report |
| SQL: syntax | Universal Function – Dashboard |
| Dynamic Syntax used inside code | Universal Functions – Dynamic Code |
| SQL: syntax | Universal Function – HTTP Trigger |
| Dynamic Syntax used in SQL | Calendars |
| Dynamic Syntax used in SQL | Kanban Boards |
| SQL: syntax | B1P&D Crystal Report Definitions |
| SQL: syntax | B1P&D Report Actions |
Comments
0 comments
Please sign in to leave a comment.