More database things I don't know about testing/publishing

kklosson

I began a significant expansion of my application that will instantiate many new business objects. So of course, I made a copy of my test database consistent with the current BSV. After doing much work, I wanted to make a very small change to the previous (CURRENT) BSV. Of course, I made a copy of my database consistent with my NEW version in development. Then I restored the database consistent with the CURRENT version and then put that version into testing. When I did so, I got an error that it could not drop an attribute that only exists in the New BSV I am working on.

This tells me that Aware IM performs a more complex analysis when putting the BSV into test or publishing than validating/updating the data structures. Why does the previous version of the BSV want to drop a column that does not exist in that version and never did?

All insights will be appreciated.

nhofkes

The databases are not linked to BSV versions. Instead, there are separate databases for testing and for published versions. So, when you create a new version and put that into testing, the new attribute is created in the test database. When you then go back to an earlier version and put that into testing, you connect (again) to the testing database and not the production database, which means that you have the additional attribute in the database which is not defined in the BSV version.

kklosson

Thank you. I completely understand that. Everything I'm talking about is relevant to the test database only.

rocketman

I tripped over something like this once. So (if I have misunderstood, apologies in advance)

1) You made some additions/changes to the BSV and put it into test mode. Test database gets updated with all the additions/changes
2) You restored an earlier version that does not contain the additions/changes and you made some small changes to that and then tried to put it into test mode
3) You restored an earlier version of the DATABASE which does not contain the additions/changes
4) so now, the earlier version of the BSV will be trying to drop attributes that physically don't exist in the restored database.

Try restoring a version of the database that has those attributes in it and see if AIM will then drop them.

My workaround (and it was a painful experience) was to go into the database and manually ADD those attributes so that AIM could then drop them. The painful bit is - if you have made (eg) 6 changes, and you only add 5 back in, AIM will fail because it can't drop the 6th (It's not there to drop) so it's back to square 1 and you have to start over. ..... Sorry!!