Glad you guys got it worked out!
Yep, you have to be carefull on filters as most uses of a BO will go off of the CurrentView, and any changes that bring things into or out of the filter in the middle of a process could cause wonky results (to put it in technical terms.)
To answer Edhy's comment regarding collision detection, collision detection in this environment should still work fine, you would just be opening yourself up to more collisions the longer you went between pulling data from the database and saving the changes back. In other words, it would likely be faster from an access perspective to pull everything you may need back to the database and the save it when you are finished, but if this is a form they will be using for 10 or 20 minutes before hitting the "save" button, you'll want to account for that based on how your users are going to use the system (i.e. how likely it is that someone will edit the same record within that 10 or 20 minutes).
Our medical application does something similar when you edit a patient record. Since patients are the central component of the system, there is quite a bit of data related to each patient's record. To account for this, we've split up the editing functions into areas of common use ("Registration" for demographic info, "Ledger" for financial transactions, "Media" for media files, etc), and handle the saving slightly differently as appropriate for each area.
The "Registration" section, for example, pulls all registration information (from about 10 tables) related to the patient at once, and lets you edit any or all of it before hitting save. If you ever navigate off the "Patient Registration" page, however, we ask you to save your changes to persist them back to the database. In the case of any data collisions, we just use the standard SF Data Collision form and methodolgy, we've just designed those areas of the system to minimize the collisions wherever possible.