I have recently split a reasonably mature application into data and interface files - it was developed for the charity that I work for, and it's now being used by another organisation (on a non-profit basis), and my motivation for splitting it was that updates would be easier. So far (and we're only a few weeks in), I've only had to change the interface file, and it has, indeed, been very easy just to swap in a new version.
However, I've recently had to change the data file - a couple of new tables, and a few new fields in existing tables. And I've obviously not grasped how that should be done. Here's what I did:
1. On the development system, made the required changes to the data and interface files.
2. Made the same (data) changes to the data files on the server, i.e. added the new tables, fields, etc. (a few days ago, in anticipation of the upgrade).
3. Made a few more changes to the interface file in the development system here (during the past few days).
4. Put the new interface file on the server (i.e. yesterday).
The new interface file, once on the server, for some reason, didn't "see" the data file correctly - a lot of the relationships were messed up, field names missing, etc. It's OK now (I think), because I've amended the interface file in situ, but at first the new features didn't work, because relationships were broken, incorrect fields were being used in script steps (e.g. the "time modified" field was used instead of the key field), etc.
As I said, this is clearly my mistake, but I really need to know where I've gone wrong, as it throws into question the whole protocol for applying upgrades. This time it wasn't a major deal, as there were only a few changes, but it could have been a lot worse.
If you can point me to a description of "best practice" for making changes, so that I can understand where I've gone wrong and (obviously) get it right in future, I would be extremely gratetful.
Thanks and regards,