I am seeing a repeating pattern that makes work more awkward than I expect it to be. This has occurred all over the system, but here are a few examples:

1) I had a VP which covered 3 of 4 access levels. I copied and pasted it to create a new VP, which I wish to apply to 1 of the access levels. There was enough content I wanted to retain that copying made sense. Now I have a conflict because there are 2 VPs covering the same 3 access levels. Fine. So I go to the original and remove the 1 level I want to use the new VP for and save. I then go to the new one and remove all but the one type to which the VP should apply. I try to save but cannot because it says the 3rd level is already covered. I go back to the original VP and reopen "Details," and the selections are as if I made no edit at all. All 3 access levels still show there instead of the 2 I left before saving. Basically, using "Details" to remove one or more access levels, which it seems to allow me to do does not save as expected. I forgot to mention I invested 15 minutes tailoring the new VP, which I now seem to have no way to use.

Question: What are the rules about when my edits will be ignored and revert to to their previous state?

2) While developing and testing, I built a view in MySQL. Of course, I needed 2 versions of the view, since the tables are differently named between the basdbtest and basdb. The Aware IM Object which I setup to acces the view was pointed to basdbtest while developing. Before I published the version, I edited this to change it to point to the basdb version. While testing I see a problem with the functionality. Review of a MySQL log shows that the query is running the basdbtest version. I removed the basdbtest version of the view to prove this is what it is doing. I search for references to the view and see the object and the one report which uses it. Well, I had copied this report as a template to build 5 other reports, and even though I had deleted the single attribute reference from the source report before completing the other 5 repots, they are still showing as having a reference to this view. They don’t seem to call it according to my log review, and they don’t bomb, but this “stickiness” is disconcerting.

Question: What are the expected behaviors when I edit a “Database existing external” and go into “Edit” and change the “Database” entry, save and then click “Discover attributes” and identify the key again? Should this work? In this case, I do not see the entry revert to its old value (basdbtest) as I did with example 1) above, but the behavior is that it still invokes the view from its original Database entry, basdbtest. Do I need to completely destroy and recreate the object to get it right? I can do this for some things, but if there are carefully crafted forms involved, I could lose a lot of work if I delete objects.

3) As I mentioned briefly in another post, I decided to try to reuse the e-mail design of the sample Library app in mine. I tried copying the objects, group, procedures, etc. from Library to mine using copy/paste. This was really an unproductive adventure. First, it was not possible to change the type of the Correspondent from “Member,” which is used in the Library app to “Person,” which is the equivalent in my app. You can’t just change the type (the combobox is disabled), which is understandable, but I completely deleted Correspondent, saved the Object, then added Correspondent back and set it to the Type “Person.” It changed back to “Member” every time. The icons were a nightmare. They referred to a folder that did not exist on my system (c:\icons_fam\icons), and I could not get rid of this even though I copied all the icons to my …\myimages folder and found and edited each icon instance (there are several) to point to my copies, it still reverted to the nonexistent c:\icons_fam\icons folder. Just to see what I could do, I went ahead and created and populated this folder with the icons. I was then able to make those changes, but I did not find a trick to resolve the “Member” versus “Person” problem, so I abandoned the effort and went and generated the documentation for the Library app, so I could rebuild what I needed from scratch. Not very productive.

Question: Is there a secret to when settings get “stuck?” Whether due to this or not, it acts as if there is a behavior in the engine feature that decides whether to save or not based on whether a difference is detected (a nice performance concept perhaps best left to runtime database activities rather than in the Configuration Tool if this is the case, since the transaction volume with the Configuration Tool is so low that performance should not be an issue…). The system seems blind to this even happening as there are no complaints or warnings most of the time.

OK, let me summarize by first saying Aware IM is an unbelievable product. I built in 7 weeks more than my team of 50 developers could have in 3 months. I am trying to understand what rules, intentional or not are in place, so I don’t waste a lot of time backtracking and redoing work.

If I have uncovered some "unintended behaviors" you would like to change, consider this my gift to help improve the product.

Your constructive comments are most appreciated.