The main problem seems to be; as the message says, invalid keypath reference(s) (external primarykey missing in either the File, Registry or the ODBCDataSource table.
Why you get this (almost) each time you start the editor is that it is setup/configured to open the last .wsi file since last time. Turn that off and the editor will start without an open existing .wsi file.

If you can't manage to get this working using the editor then fire up InstEd (or ORCA) and perform an ICE validation and it should point you to the invalid keypath(s). Correct it, save and then open it in the windows installer editor.

1. I start with a WSI that is not giving any errors.
2. I make a simple change and save (or make no change at all and simply save)
3. I load the WSI back in, and get the message (sometimes).

What should I look for as the source of the error to begin with?

My hunch is that I have some folders that are autopopulated with wild cards, and maybe there is something about that that Wise does not like????

Thanks!

Carl.

Don't sound like invalid folder if you don't have an empty KeyPath column value for a Component table entry. Verify this first.
Do you have any macro that performs some automatic things?

Do you get any ICE errors while performing a validation?

If you are changing a file that is wildcarded, then Wise needs to be able to rescan the wildcard and reload the new values.
If you have just changed a wildcard, it's version information or MSIHASH will no longer be valid based on the previous entry in the WSI file, and if that file also happens to be a keypath, then you will get errors as the keypath is no longer valid based on the previous entry.

I don't think I have to change anything to get the problem to occur.  I think all I need to do is open my WSI, then click on "Save", and there is a 25% chance it will get corrupted.

It just happened to me again.  Here are the steps to repeat in this particular case:

1. I opened my WSI
2. I went to "execute immediate", and clicked on one of my custom actions, then clicked on the "Move up" arrow to move the action to occur one step sooner
3. I clicked on "Save" to save my WSI
4. The save took about 15 minutes to save (normally it only takes about 2 or 3 minutes)
5. I closed Wise
6. I opened Wise
7. I got the "Invalid key paths" error again.

Note that whatever I do in step #2 seems to not matter.
Note also that it seems I can predict the error will occur by how long it takes my wsi to save.

Continuing on, I went ahead and chose "ok" for the error message, then went to "Setup Editor", and clicked on the "Components" tab, and Wise then locked up for several minutes.  Once it unlocked, I clicked on teh "Tables" tab, then used "find Error" to see what it might find (I'm totally guessing at where to look here.), and under "MsiFileHash" I see a bunch of my files, and they are colored red.  Maybe this is important, I don't know????

So, next I went to the "Installation Expert", and chose the "test" option.  It then locked up for about 10 minutes, then compiled then gave me another message with the option to fix invalid key paths.  I chose "Yes", which opened up a window named "Remove missing files" which had grayed out "next" and "Back" buttons, and it said "the following files have source paths that are missing or invalid.  Select the files to remove from this installation", but then showed no files at all, and the only option for me is "Cancel", so I did.

So, I will now do what I always do, which is to try to remember the changes I made recently, restore from a backup, and re-do the changes...

This does indeed sound like a bug, so if you are not running SP1, it may be worth updating to SP1 in order to see if this problem persists.

I'm running all the latest Wise updates.  Oddly, the problem has mysteriously disappeared, and I have not seen it occur since my last post.

It may be related to the EdT's question "Is it a wild card file you are changing", I'm not sure, because I have a lot of wildcard folder scanning going on, and I use batch files to prepare temporary folders and such.  Perhaps if the batch files skip something, it goes nuts.   I've been avoiding running the batch files, and this may be why it is more stable.

Carl.