How to manage order dependencies between AppSearch entries?
In my case, I want a RegLocator to check for a path out of the registry and then I want Signature.Parent to use the path results of the RegLocator. Here's my implementation in tables...
TeleForm Workstation Directory
With this authoring INSTALLDIR (resolved by the IniLocator) does not resolve by the time I need to use it in the DrLocator.Path
Unless the order is explicitly specified in the table via an "order" column or guaranteed through some method explained in the documentation, you should NOT rely on or assume any particular ordering within a table.
The concept of "order" in an MSI table is specious. MSIs are relational databases with no inherent order. Maintaining order in a table is not a guarantee of the MSI file format, and therefore any operation that touches the MSI file is perfectly within its rights to completely reorder the rows in the table inside the file. Simply opening and closing the MSI file could reorder the rows, as could "save as...", or poking the summary info, to say nothing of any operation that actually updates table data such as patch application or transform customization. Even then, nothing in the MSI SQL engine guarantees a particular retrieval order unless the SQL statement includes an ORDER BY clause. And nothing says Orca has to show the rows in a particular order either, unless you've sorted on a column and even that is merely a UI change. In fact there are scenarios where Orca does NOT show things in the order retrieved from the database.
Do not try to reverse engineer the behavior of the table processing. It could work fine by pure luck for months or years and then your third patch causes things to go crazy - you'll never know.
Off-line it was suggested to me that if there was specific sequencing required, one should use custom actions explicitly sequenced in the appropriate sequence table.
MSI MVP Stefan Krueger pointed out that the original post (without the tables) did not make sense in the light of MSDN article Searching for a Directory and a File in the Directory. After reading through the original query, the code and the SDK, I believe pinpointed the problem in the authoring. One can't use the value of the Property but one can connect the dots using the Parent column and pointing it to the earlier Signature_.
Content credit also belongs to