Hi Dave,
After being let go by Explorer Software at the end of 2018, I have followed a 5-months training last year followed by a 2,5 months internship. The goal was to gain skills in mainstream web development languages & frameworks (PHP, Symfony, Java, Android, Javascript/jQuery, IONIC/Angular/Typescript, MySQL, MongoDB) as well as modern software design (UML, Object Oriented multi-layered apps, Relational Database Design). I needed to find another job and since you can consider the french ProvideX market as slowly dying, it was time to move on.
Although my past experience with ProvideX allowed me to get in touch with SQL & RDBMS as well as the ProvideX implementation of the object paradigm, it was also the very first time in 30 years I was seeing Classes diagrams and E/R diagrams as well as the methods and techniques to build them.
In 1986-88 french software programming schools, you learned COBOL and GW-BASIC, using the built-in ISAM files for one, and building them yourself for the other. I also learned a bit of dBASE III+ during the second year. No SQL courses and no UML / OO design at the time.
When I joined my first employer in 1989, they were still using Tbred, I was the one who discovered ProvideX and advocated for the migration of the application. There were some attempts to migrate the ISAM files to SQL backends, but all were cancelled before being completed. The only documentation available when you started working on the software were the file layouts. Which could not be imported into the PVX Data Dictionary as the files were non-normalized and the DD did not support them back then (around 99-2000, before PVX V5).
When I joined Explorer in 2008, their SQL migration had been done for years. However I never saw any ERDs there, not even a Merise Physical Data Models.
In my experience, when you migrate ProvideX files to SQL, you only change for a different data store, and rarely enable all the power of the RDMBS engine -- I can be wrong, but I don't think after migration, people add foreign keys constraints to enforce referential integrity. Either your legacy BB application stores data forever without any archive/purge, or it does purge files but has referential integrity checks already programmed at the app level, when a user wants to remove some static data (a customer, a vendor) and the system needs to search all the transactional data (invoices, orders, etc...) to make sure the entity to delete does not exist anymore in your detail files.
BTW, I passed a final exam on January 8th. The official results are unknown yet (probably next week) but I got some not-official info from the main trainer who discussed with the examiners, and he told me not to worry about it ;-) I now have the equivalent of a BS degree in software design & development (I only had an associate degree from 1988). I am also in the process of creating a small one-person consulting & development services company to do free-lance work for the company where I did my internship (using ASP.Net MVC with C#). If you need any help with your db courses, feel free to pm me, I'll be happy to help an old fellow ProvideX programmer ;-)