Why the Monster QFE Packages?

In January we released the Beta version of the new QFE format. “Oh no!” I hear you say, “What do I have to do now to keep my database up to date?”. Well, the reasoning behind the change is to make it easier for customers to keep their Embedded database up to date.

One of the challenges we faced with releasing component updates was that, unlike XP Pro, we could not rely on everything “just being there”. What that meant was that if one component within a sld took a change in QFE1 and then another component within the same sld took a change in QFE2, both fixes would end up in the second month’s QFE package. Something like this –

The problem was that, if customers only installed Q2, then they would only get half of Q1 in that installation (foo.dll (Q1), but not Bar.sld). To overcome this we rolled previous QFE’d slds into current QFEs (Bar.sld would also ship in Q2), but as time went on these packages were growing bigger and bigger as we had to include more and more slds.

The second challenge we needed to address was the difficulty our customers faced having to locate and install this multitude of QFEs. It was difficult to keep track of what had been installed and what had not.

 In order to solve these two problems we redesigned how we package QFEs. We rolled all of the security QFEs that were ever released for SP1 into one giant sld and used that as the base of every new QFE. Each month we add the new QFE components to it. Although it is still cumulative and so grows larger every month, the advantage is that there is only one QFE sld to import every month. It also ensures that all the previous QFEd components are always present.

- Lynda