Brian and Symeon, since mv.NET is wrapping UO.NET, the issues you mention don't apply: - Bill isn't managing the UO.NET API calls, so he has no control over them. - Once the connection is established, only one client process has access to any given server connection. Therefore, no multi-threading. - mv.NET actually does interface through a BASIC call as described.
Regarding large items, I'm not sure what's happening at that level but I believe it's handled properly. I would comment that a return value should not cause a component like UONET.DLL to log a vague error without throwing an exception, and that if this is a recognized issue that it should have been addressed a long time ago. If there are function calls that are known to be flaky outside of subroutine calls, I would also hope that these have been documented and passed to RS for resolution. The next step in the diagnostic for anyone with these mystery logs would be to put Symeon's trace flags into web.config. That information can then be sent to RS for comment. T _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
