Table Structure Changes v. Preexisting BOM configs. How to Control?


Author
Message
Alex Luyando
Alex Luyando
StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)
Group: StrataFrame Users
Posts: 112, Visits: 1.2K
I may be missing something, but the following scenario has me concerned.



Starting with a working application that includes several business objects, the following steps/observations have taken place.



1.) For some of the SQL Server tables, columns were added, renamed and deleted. Previously BOM sessions had configured several business objects to these tables.



2.) I expected a subsequent BOM Rebuild All to "complain" about the columns touched in step 1.), but instead got an "All OK" on the rebuild.



3.) Spot checking of the columns in the BOM for one of the tables heavily modified shows that the BOM resynched with the target SQL Server table and has renamed (and new) properties based on the "new" column names.



4.) I then rebuilt the application and again, no problems.



5.) Of course, as soon as I ran the application and accessed a form that has controls bound to the "old" BO properties errors were thrown.



Obviously the solution is to go into each of my forms that use any business objects that were impacted by my database schema changes and re-data bind. That's not a biggie.



What is of concern to me is understanding how to control this type of scenario from playing out, especially in a multi-developer environment. Clearly any change to a SQL Server structure can cause existing (deployed) applications to fail if their BOs are expecting certain column's to exist. That has to be controlled via a formal change control policy.



In the case outlined about though, I would hope we could find out either at BOM time or build time, that there are data bindings that no longer make sense. Certainly I'd like to find out before testing or deployment. I'd image this type of control could be a problem if data binding "mismatches" are resolved at run-time, but perhaps some customization of the BOM/Build-time validation could handle these cases and prevent false alarms. Perhaps VS Pre/Post build hooks could be used?



Am I worried about something I shouldn't be?



TIA


________________
_____/ Regards,
____/ al
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search