none
Is SExistRestriction necessary? RRS feed

  • General discussion

  • Hi everybody,

    Is SExistRestriction necessary while building a restriction when that the property exist every time?

    1) In msdn.microsoft.com/en-us/library/cc839617(v=office.12).aspx in last line, the author didn't suggest to check existence of PR_RESOURCE_FLAGS property.

    2) In msdn.microsoft.com/en-us/library/cc815385(v=office.12).aspx in one paragraph, it is again suggested to check for existence of the property before passing to IMAPITable::Restrict or IMAPITable::FindRow. What if the developer is not passing the property restriction to IMAPITable::Restrict or IMAPITable::FindRow. Is checking for existence of a property necessary in this case also (when the developer is not passing the property restriction to IMAPITable::Restrict or IMAPITable::FindRow)?

    Thanks & regards,

    Talib Hussain





    Wednesday, June 11, 2014 1:16 PM

All replies

  • If you have a restriction (any restriction) on a particular property, and the property does not exist, the result will be unpredictable. That's the only reason to use SExistRestriction.


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Wednesday, June 11, 2014 1:23 PM
  • Hi Talib,

    No, it is not necessary. The keyword for such advice is *when that the property exist every time*.


    Wednesday, June 11, 2014 1:23 PM
  • Actually, if the property is not one that's always on the object then it is necessary. Otherwise, as Dmitry mentioned the results of the restriction will be unpredictable.


    Ken Slovak MVP - Outlook

    Wednesday, June 11, 2014 1:49 PM
    Moderator
  • And the only property that is always guaranteed to be present is PR_ENTRYID. So it is a good idea to always use RES_EXISTS. At the very least it won't hurt.


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Wednesday, June 11, 2014 2:11 PM
  • So if you're restricting on anything other than EntryID the best practice is to always check for RES_EXISTS.

    Ken Slovak MVP - Outlook

    Wednesday, June 11, 2014 2:45 PM
    Moderator
  • It is not a requirement. And based on the initial message which states the following - "when that the property exist every time", it is not necessary.
    Wednesday, June 11, 2014 2:45 PM
  • Not a requirement, a best practice. And the only property guaranteed to be there is EntryID.

    If the poster wishes to code with non-best practices that of course is up to them, it's not something that should be recommended.


    Ken Slovak MVP - Outlook

    Wednesday, June 11, 2014 3:02 PM
    Moderator
  • Hi Dmitry,

    As asked in the first point in the question, in msdn.microsoft.com/en-us/library/cc839617(v=office.12).aspx, in the last line, the author didn't ask to check for existence of PR_RESOURCE_FLAGS property. That's why I was having that doubt - whether to check for property existence or not.

    • Edited by talib2608 Thursday, June 12, 2014 7:13 AM
    Thursday, June 12, 2014 4:17 AM
  • Hi Ken,

    As asked in the first point in the question, in msdn.microsoft.com/en-us/library/cc839617(v=office.12).aspx, in the last line, the author didn't ask to check for existence of PR_RESOURCE_FLAGS property. That's why I was having that doubt - whether to check for property existence or not.
    • Edited by talib2608 Thursday, June 12, 2014 7:12 AM
    Thursday, June 12, 2014 4:19 AM
  • It is just a recommendation to check it before doing something against a property to be sure that your code will return expected results.
    Thursday, June 12, 2014 10:20 AM
  • The code in articles isn't always be complete production code. In fact it usually is not. As an example it probably won't have full error handling. I would recommend that you check for the property. It's not hard and can prevent unexpected results in your code.

    Ken Slovak MVP - Outlook

    Thursday, June 12, 2014 1:54 PM
    Moderator