Installing the SF 1.6.6 Beta update, I got an error when Building StrataFrame Databases.  Please see images attached.

The process is looking for a Triggers.xml file.

See attached image for a list of files in this folder: C:\Users\Edhy\AppData\Local\Temp\MicroFour\Metadata

Doron Farber, installed the update without a problem and I asked him to send me the trigger.xml file and I copied to the expected location, ran the setup again and it finished without any error.

Here is my Version status in the attached file, which I believe is not OK, so once again in my setup something is not right, but nothing to worry about it, I am getting used to the install not working on my setup without some manual help

Some possible reasons the StrataFrame.Pkg file did not get overwritten:

1. Insufficient permissions
2. File was open by another process (unlikely unless you manually opened)
3. Real-time virus protection attempted to scan and prevented the update of the file.  I have seen this more and more lately....I am not a real-time anti-virus fan.  In fact, I have dealt with viruses that are not as mean as the real-time stuff...OK, that is enough of a rant on that point!

I would check these and see if any are possibilities and try again.  The installation does work so something is getting in the way of the files being updated...all of this falls in line with standard MSI coding standards.

This says a lot about what you may be facing, also your screen shot says a lot as well.  This is clearly not the norm otherwise this would be a major issue for us all. 

If you'll notice, your assemblies are not getting updated.  This could all come from my previous posts suggestions.  All of your files should show a version of 1.6.5.2.

• I disabled all antivirus, spybots, etc.
• Uninstalled SF and manually remove the assemblies from the C:\WINDOWS\Assembly
• Reboot
• Reinstalled SF and got same missing file error, and canceled the installation.
• Copied the Triggers.xml to C:\Users\Edhy\AppData\Local\Temp\MicroFour\Metadata
• Reinstalled SF and it completed.
• Checked SF version and had the same screenshot as before with different versions.
• Checked SF assemblies in C:Windows\Assembly and they all have correct version 1.6.5.2
• Checked SF assemblies in C:\Program Files (x86)\MicroFour\StrataFrame\Assemblies and they are also correct 1.6.5.2
• Now last place to check C:\Program Files\Common Files\MicroFour\StrataFrame here the assemblies where not updated, they all have version 1.6.5.1 (see image attached) and also I believe this may be the caused of the missing file since the *.pkg files may not be updated.  So for now my fix was to copy the correct assemblies to C:\Program Files\Common Files\MicroFour\StrataFrame.

Tomorrow if I have some time or in the next update I will do all steps above and will also manually remove C:\Program Files\Common Files\MicroFour\StrataFrame before installing to see if that takes care of future installations.

P.S.

I am very happy with all new features added, specially those related to the ListView which I use a lot in my current project.

Yeah, we have been using this extensively as well...so that keeps the features coming

One thing I thought I would point out on this new release is the BOs SaveCurrentDataTableToSnapShot and RestoreCurrentDataTableFromSnapshot methods.  These were implemented specifically for the ListView and performing Undos if their was a cancel out of a child dialog form.  The complication without this was the following scenario:

1. Add a new child record
2. Click OK on child dialog to close the child and keep the new child record in the BO
3. Select the new child record from the ListView and edit the record
4. Click cancel

At this point prior to this method, if you performed an Undo you lost the new record because it technically still had a RowState of Added.  With the Save and Restore snapshot methods, you never need to call Undo.  You should always let the ListView perform an automatic snapshot (does by default) then just call the Restore if the end-user cancelled the child dialog.  This way it is always 100% accurate in regards to what the end-user has been doing.

Thanks for explaining this in more detail.  Today I will start testing those new changes.

BTW, you won't believe this, but 2 days ago while testing a form which has 2 listview controls, as an end user, I felt the need to add a DoubleClick action to edit the selected record, and boom! you just implemented that feature in this release, it couldn't be better than that!

Cool