Issue 29364: msilib Fetch raises MSIError rather than return None (original) (raw)

Issue29364

Created on 2017-01-24 18:54 by Jason Matthew, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg286204 - (view) Author: Jason Matthew (Jason Matthew) Date: 2017-01-24 18:54
Fairly new to MSIs here. Working towards extracting the same information which is available via Orca graphical interfaces. I believe I've hit a bug within _msi.View class, namely the inability to safely determine the number of records in my result. Examples I've found depicting how to obtain query results lead me to believe _msi.View.Fetch() will return None if no more rows exist. My development using python 2.7.11, Windows 7 enterprise and 2.7.13, Windows Server 2016, has shown Fetch() will raise a msilib.MSIError when no more rows are available. MSIError is commonly used within msilib which means explicit error handling (or leniency in this case) may incorrectly suppress other error scenarios. Entering a bug with the hope either a patch addresses this issue or documentation can be updated to reflect proper usage. Example provided below. >>> import msilib >>> db = msilib.OpenDatabase("msi-1.0.0.8.msi", msilib.MSIDBOPEN_READONLY) >>> v = db.OpenView("select * from Property") >>> v.Execute(None) >>> while 1: ... r = v.Fetch() ... if not r:break ... print r.GetString(1) ... UpgradeCode WixSharp_UI_INSTALLDIR WixSharp_InstallDialogs WIXUI_INSTALLDIR Manufacturer ProductCode ProductLanguage ProductName ProductVersion SecureCustomProperties Traceback (most recent call last): File "", line 2, in _msi.MSIError: unknown error 103
msg286669 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2017-02-01 17:52
Thanks for the report, Jason. I think this is a duplicate of issue 1102. The second patch (_msi_fetch.patch.txt) there should fix your problem (if I read MSDN correctly, 103 is ERROR_NO_MORE_ITEMS.) I don't have access to a Windows box at the moment so could you please verify my theory so we can close this as a duplicate?
msg286679 - (view) Author: Jason Matthew (Jason Matthew) Date: 2017-02-01 19:32
Thanks for pointing that one out Berker. I agree, this is a dup.
History
Date User Action Args
2022-04-11 14:58:42 admin set github: 73550
2017-02-01 19:34:04 berker.peksag set superseder: Add support for _msi.Record.GetString() and _msi.Record.GetInteger()stage: resolved
2017-02-01 19:32:23 Jason Matthew set status: open -> closedresolution: duplicatemessages: +
2017-02-01 17:52:18 berker.peksag set nosy: + berker.peksagmessages: +
2017-01-24 18:54:25 Jason Matthew create