SOLVED
Home

SP2016 Application using BCS IEntityInstanceEnumerator

%3CLINGO-SUB%20id%3D%22lingo-sub-815347%22%20slang%3D%22en-US%22%3ESP2016%20Application%20using%20BCS%20IEntityInstanceEnumerator%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-815347%22%20slang%3D%22en-US%22%3EI%20have%20recently%20began%20re-work%20a%20custom%20.NET%20applications%20and%20have%20migrated%20it%20from%20.NET3.5%20on%20SP2010%20(dev%20on%20VS2010)%20to%20.NET4.52%20on%20SP2016%20(dev%20on%20VS2017).%20Everything%20has%20ported%20fairly%20seamlessly.%20However%2C%20I%20have%20been%20diagnosing%20an%20issue%20with%20the%20BCS%20data%20retrieval%20using%20the%20FindFiltered%20method%20into%20IEntityInstanceEnumerator%20(IEIE)%20interface.%20When%20the%20call%20completes%2C%20and%20the%20subsequent%20MoveNext%20call%20is%20executed%2C%20an%20error%20occurs%20indicating%3A%20External%20ItemEnumerator%20is%20closed%20The%20model%20I%20have%20imported%20and%20setup%20still%20contains%20all%20valid%20pieces%20and%20permissions...each%20item%20container%20ReadList%20and%20ReadItem%20operations.%20I'm%20now%20using%20Kerberos%2FClaims%20w%2F%20valid%20SPNs%20setup.%20I%20can%20see%20the%20valid%20query%20call%20to%20SQL%20both%20in%20ULS%20logs%20and%20in%20SQL%20profiler.%20I%20have%20turned%20on%20VERBOSEX%20and%20retrieved%20no%20additional%20clues.%20The%20odd%20thing%20is%20in%20other%20parts%20of%20the%20application%2C%20if%20we%20push%20the%20returned%20IEIE%20into%20the%20CreateDataTable%2C%20we%20can%20process%20this...so%20it%20seems%20the%20data%20exists.%20I'm%20trying%20not%20to%20have%20to%20refactor%20several%20areas%20if%20I%20can%20find%20a%20reason%20why%20this%20would%20be%20occurring.%20Thanks%20for%20any%20ideas%20(and%20I%20will%20provide%20more%20info%20as%20requested).%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-823561%22%20slang%3D%22en-US%22%3ERe%3A%20SP2016%20Application%20using%20BCS%20IEntityInstanceEnumerator%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-823561%22%20slang%3D%22en-US%22%3E%3CP%3EFWIW%3A%20It%20was%20determined%20that%20the%20use%20of%20the%20using%7B%7D%20statement%20was%20the%20cause%20of%20the%20issue.%26nbsp%3B%20It%20was%20causing%20the%20disposal%20of%20the%20object%20that%20was%20being%20returned%20to%20be%20cleared%20before%20it%20could%20be%20used%20back%20in%20calling%20function.%26nbsp%3B%20It%20appears%20that%20this%20it%20was%20not%20fixed%20until%20.NET%204.5%2C%20which%20is%20why%20it%20did%20not%20%22raise%20its%20ugly%20head%22%20until%20now.%26nbsp%3B%20I%20have%20removed%20the%20using%7B%7D%20statement%20and%20moved%20to%20calling%20function%20in%20those%20particular%20areas%20and%20all%20is%20good%20now.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F396018%22%20target%3D%22_blank%22%3E%40Lignite%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Lignite
New Contributor
I have recently began re-work a custom .NET applications and have migrated it from .NET3.5 on SP2010 (dev on VS2010) to .NET4.52 on SP2016 (dev on VS2017). Everything has ported fairly seamlessly. However, I have been diagnosing an issue with the BCS data retrieval using the FindFiltered method into IEntityInstanceEnumerator (IEIE) interface. When the call completes, and the subsequent MoveNext call is executed, an error occurs indicating: External ItemEnumerator is closed The model I have imported and setup still contains all valid pieces and permissions...each item container ReadList and ReadItem operations. I'm now using Kerberos/Claims w/ valid SPNs setup. I can see the valid query call to SQL both in ULS logs and in SQL profiler. I have turned on VERBOSEX and retrieved no additional clues. The odd thing is in other parts of the application, if we push the returned IEIE into the CreateDataTable, we can process this...so it seems the data exists. I'm trying not to have to refactor several areas if I can find a reason why this would be occurring. Thanks for any ideas (and I will provide more info as requested).
1 Reply
Solution

FWIW: It was determined that the use of the using{} statement was the cause of the issue.  It was causing the disposal of the object that was being returned to be cleared before it could be used back in calling function.  It appears that this it was not fixed until .NET 4.5, which is why it did not "raise its ugly head" until now.  I have removed the using{} statement and moved to calling function in those particular areas and all is good now.

 

@Lignite 

Related Conversations