Hey Marc,
To answer your question, you need to call MsiDatabaseCommit function after
you make change.
Understand that you cannot permanently persist the changes into the msi file
if you are doing
it from a CA of the running MSI. You can find more details here
http://msdn.microsoft.com/en-us/libra
In case anyone's still wondering how to modify the in-memory copy of the MSI
database here are some pointers.
You can't do much with using SQL command to modify the database (using
UPDATE, DELETE, ...). If you want to modify a existing row, do the
following. First, open up the view containing the
Thank you guys both for so much. But would you explain more on how I can
specify my intention of modifying the in-memory copy of the MSI? When using
MsiDatabaseOpenView, I tried to use "UPDATE `Component` SET
`Component`.`Attributes`='256' WHERE
`Component`.`Component`='AuthPluginRegistry' TEMPORA
Thank you, I appreciate that . And once we do MsiDatabaseCommit(), will the
change be persisted onto the msi file permanently, or would the change be
valid only for the duration of the current installation session?
Rob Mensching-6 wrote:
>
> It means your changes to the MSI database won't be pe
Just to clarify one thing. The reason why I don't want to use msidb.exe is
because the program does not return any command line error values.
--
View this message in context:
http://n2.nabble.com/Is-there-a-Windows-Installer-API-for-extracting-cabinet-files--tp2602175p2602299.html
Sent from the
My exit code has a meaning. That's why I wanted to write my own "return code
processor."
If I ignore the return code, I'll be okay in situations where the exe
returns a success code 1,
but what if it returns 3, 4, 5, ... other error codes. I wouldn't be able to
process these error codes.
If the
6 matches
Mail list logo
