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

Hi ALex,

FWIW - I think your problem is way further up the food chain than the BO's. Having multiple developers making uncontrolled schema changes to existing applications sound like the stuff of nightmares. Fist cab of the rank, in my opinion, is a bit of order in your shop then, when you have a change process in place, think about how to propergate (known and approved) changes into your apps.

Cheers, Peter

Well, this can be handled a number of ways, but generally it will require some level of auditing or notifications from other developers.  Developing in a team environment is never a perfect world...especially if the other developers make a massive change to any structure and do not share that information with the rest of the team, somehow. 

To explain the issue, the binding field is a string so technically it is weak typed and not evaluated until run-time.  We work in a team environment here as well and on our medical application.  However, when we make a structure change, we know that there is the potential for others to have an issue.  So we talk with other team members if there is a chance that this could cause an external issue and we also use the Team Foundation tasks, etc. so that other developers may be made away.  Usually, the developer who makes the structure change is responsible for making sure that any downstream issues get resolved.

Now, back to your original point and question, it is our desire to force strong-typing into the forumla in a future SF version.  But this is much more difficult than it would seem.  In fact, native .NET data-binding is not stong-typed either....that is one of the pieces that holds this process back.  So for now, the best rule of thumb is to develop some good internal policies.