Timeline for Error on ECL items that are removed from source repository
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 15, 2015 at 19:52 | comment | added | Vipin Kothari | removed the coreservice part from my answer | |
| May 15, 2015 at 19:16 | history | edited | Vipin Kothari | CC BY-SA 3.0 |
removed the part for CoreService usage as it seems that is not going to work
|
| May 15, 2015 at 6:16 | comment | added | Lars Møllebjerg | I already did write an answer - the provider is broken (given the limited information available). Sure if you are running software without any form of support so you can't even get bugs fixed it can be needed to implement a workaround, but I will always consider that option as a last resort. | |
| May 14, 2015 at 17:12 | comment | added | Vipin Kothari | @LarsMøllebjerg for customers like us who do not own\have the source code for ECL layer (Tridion side ECL connector or the third party side connector), the option I suggested is one of the plausible option to prevent this issue from happening. Also, I am not clear of what option you are suggesting in your comment. It will be great if you can write your approach as an answer as it will help the community and its users a lot :) | |
| May 14, 2015 at 5:57 | comment | added | Lars Møllebjerg | Also do notice that you will not get an exception when reading the item through the core service even if your provider is broken. The error happens in the UI layer. | |
| May 14, 2015 at 5:55 | comment | added | Lars Møllebjerg | Why not just fix the ECL provider? And if you want to add locking of items in use on the remote system what is the benefit of using the standard Tridion event system instead of the stub create/delete methods being called in your provider? | |
| May 13, 2015 at 21:14 | history | answered | Vipin Kothari | CC BY-SA 3.0 |