3 ms·

I use AS/400 in 2024, though not that much anymore because we only have a few things left in there that haven't been migrated. What we have gone to is less reli

I use AS/400 in 2024, though not that much anymore because we only have a few things left in there that haven't been migrated. What we have gone to is less reliable and getting data out of it is always a herculean effort that requires a bunch of service tickets and meetings. One of the great features of AS/400 is I think shift+esc, which allows you to quickly view the list of tables (or files as they call them) that are being used to populate the current screen. This should be a standard function for Tableau/Power BI workbooks that have live database connections. I have a love-hate relationship with it. It's like an old pickup with 1M miles that refuses to die.

ako 3y ago
How do you use that info? Validate that it’s using the correct data, or as info when writing a new app? I often wished I had the same when building something on top of sap/salesforce/any other app that would show the source of every field on a page, ideally also showing the api that would give that data.
- internet101010 3y ago
  When people say "I want the <insert metric> from G42" with G42 being a certain screen, it's helpful to be able to quickly see what all is populating that screen. It's not exact but over the course of 30 years a lot of tables can get created and 7-8 character limits on table and field names doesn't help. I am not sure if it is a requirement when creating a table to have descriptions but they are all there in my org. So go to the screen to get the tables and then join it with a "give me the list of all tables, table descriptions, columns, column descriptions" SQL query. EZ. After seeing how useful these descriptions are, I firmly believe that every organization should make them a requirement even if the rdb itself does not. Just simple form of documentation at time of creation that allows for context while still giving you the ability to enforce rigid naming structures.

ako 3y ago

How do you use that info? Validate that it’s using the correct data, or as info when writing a new app? I often wished I had the same when building something on top of sap/salesforce/any other app that would show the source of every field on a page, ideally also showing the api that would give that data.

internet101010 3y ago
When people say "I want the <insert metric> from G42" with G42 being a certain screen, it's helpful to be able to quickly see what all is populating that screen. It's not exact but over the course of 30 years a lot of tables can get created and 7-8 character limits on table and field names doesn't help. I am not sure if it is a requirement when creating a table to have descriptions but they are all there in my org. So go to the screen to get the tables and then join it with a "give me the list of all tables, table descriptions, columns, column descriptions" SQL query. EZ. After seeing how useful these descriptions are, I firmly believe that every organization should make them a requirement even if the rdb itself does not. Just simple form of documentation at time of creation that allows for context while still giving you the ability to enforce rigid naming structures.