>My guess is that there's some piece of UT's architecture that doesn't sit well with whatever UT.net uses for data, and with which VFP was quite at home. Well, maybe if Michel decides to write a book...
Everything seems to be related to the VFPOleDb provider. This is what we have been dealing with since the debut on several projects since I started to use it. So far, in a test environment, under SQL Server, I haven't been able to reproduce the problem. This is a known issue. Microsoft knows about it and so far, at the VFPOleDb provider itself, there isn't a workaround. I have received some code last fall from Microsoft about a new design in the way to use the provider but that implementation was not applicable for me. This weekend, on another big site, we have a full scale migration to SQL Server. I will know more about it next week. Basically, the issue at the VFP level is that we have to set up some code to reissue certain requests as, a request that can work 999 times out of 1000 may fail at once for no reason returning up to 12 different VFP messages when the error occurs. The code is good and there is nothing wrong with it. But, occasionnaly, we have to issue the retries so the user never knows about it and the request finally terminates ok. So, that is one issue. Another one is the memory problem which can occurs at any time, but mostly after a few hours of activity with a few or a lot of users. It just happens like that. As a workaround, and that has helped so far, we have fine tuned some settings at the IIS level to recycle more often. It helps but it doesn't resolve the situation entirely. Recently, I had some weird issues about IIS being stopped by itself for no reason at every 12 hours approximately. With the .NET Framework 3.5 SP1, since I have installed it yesterday morning, that issue has not been seen so far.
As for the UT, we cannot go at SQL Server presently as I need to complete the migration of the code first. Once done, we will be able to move to any backend without changing the code at the application level. So, once the migration completed, I will be able to set up a test environment for a SQL Server backend and that would be interesting to get the stats. Basically, the SQL Server provider is 3 times faster than the VFP provider. SQL Server is more native to .NET so that is probably why it is working much better. Also, with the SQL Server provider, we do not have to retry on failure as this never happens (in reference to the problem we have as mentioned in the above paragraph). I also expect the memory problem to go away as this seems to be also related to the VFP provider.
Also, the move to SQL Server will allow me to use SQL Server full text indexing and get rid of the old PHDBase design which is causing me a lot of problems to evolve.
So, there's a lot of interesting things coming up.
For now, I still have a few options to complete at the message level and the private message level. Other than that, we'll be able to test all that with a SQL Server backend on a test environment.
