>>I have a workstation which is doing a lot of SQL across the net. When those SQL are executed on the server where the tables reside, it's fast. However, across the net, it takes more time for the workstation to obtain the results. I am trying to optimize those queries. In most of those queries, I don't use NOFILTER. Would that be of such a help? All my SQL are optimized as per Rushmore. It's true that between PCs, I have Ethernet 10 and not 100. But, for now, we can't change cards. So, what else could I look for?
>
>Michel,
>
>This sounds much like one of those cases where Walter M. (and lately Hilmar Z.) frequently comment that 'sometimes FULL optimization is too much optimization'.
>
>The most common example is the TAG on DELETED(). It causes far too much network traffic in 99% of cases of LARGE tables, making for much slower response.
>
>That example can be extended to any other TAG that might have a VERY limited number of values (as DELETED() can only have 2).
>
>In this case it is best to:
>1) Ensure that your SELECT is FULLY optimized for Rushmore;
>2) Start deleting TAGs one by one, begining with DELETED() if it exists and re-trying BETWEEN each deletion. Obviously the next subject TAG would be the one with the fewest possible values (for example, male/female code if one existed).
>
>Bets are this will make a substantial difference.

We're working with SET DELETE ON, and I'm my book and from what I was told in several years, that we should have a tag on DELETED(). Unless, this has changed in the last versions. Isn't it the case? Any comment on that?

I will verify again. In the mean time, I have increase the timer in that robot application to only execute those SQL every hour instead of every 15 minutes.