Hi, thank you for your reply.
The link in the answer, marked as correct does not work.
Apart from this I'll stick with the code change using AFObject.FindObject, because even with worse performance it is preferable than a regularly running sql scripts solution.
1 of 1 people found this helpful
CORRECTION. It's a typical Monday.
The behavior is quite explainable. In your first usage, you have passed a pural of paths. In your second line of code you are passing a singular path. Have you tried using:
Also note remarks for FindAttributesByPath:
The performance of finding attributes by path can vary depending on the syntax, server version, path length and hierarchy depth. For best performance, make sure you are using the latest AF Server. Simple relative paths (no substitution or navigation up or across the hierarchy) will perform better. Element paths which exceed a length of 420 characters or an element depth of 24 levels will execute slower.
Hi Rick, thanks , but i think the explanation is actually in the posts you cited which explain the not working behavior (stating it is a known problem in the Sdk).
In the sample code I posted, the second line is just for simplicity, in the real code the second call is used in the loop in order to retrieve all paths.
The real question was why the bulk call is sometimes not working while it should (since it is designed for it).
I haven' tried the code you posted, but probably, even if it is working (which I would rather not count on since the same method does not work with plural paths), it probably wont make signifficant difference compared to the approach I've chosen - they both retrieve the attributes one by one.
By the way, thank you for the performance remark. Some time ago I noticed very slow performance in search by path (for elements, not for attributes) and I believed that the reason was recursive query in the AF Database which i managed to found. If that is improved in the AF Server (database) in the latest version this is great.