What SYS(3054,11) returns in both cases?

>I *really* need some help on a problem baffling me. Something has changed but, honestly, neither my manager nor myself can figure out what!
>
>Background (in a nutshell):
>We have a multi-user VFP application that has run well for years.
>It's currently running under VFP8.
>
>One part of this application sometimes does a "Select - SQL" lookup on another department's .DBC. This lookup has taken approximately 1 second.
>
>I recently added six small non-indexed fields to the lookup table in the "other" department's application.
>
>The problem:
>The next day users in the "first" application found that the lookup time increased from 1 to (now) 18 - 20 seconds. Please note that the "first" application's code is absolutely UNchanged!
>
>When I do the same lookup in a non-production "development" .DBC, I still get the quick (1 second) results. Otherwise, I too get the big delay. (Both tables' record counts are quite similar and the new fields are also in the development table.)
>
>Both .DBCs, production and development, are on network servers (not local). The issue is reproducible and results depends upon which "other" .DBC, production or development, I do the lookup on.
>
>Here are some basic facts, related or not:
>
>1) During this period our network has not changed.
> (My manager is the network administrator.)
>
>2) All users now encounter the same issue.
>
>3) The problem is server independent. That is, the "production" data when
> copied to the "development" server exhibits the identical 20 second delay.
>
>4) When the fields were added to the "other" department's production table,
> I used VFP9, not VFP8.
>
>5) At that time I also reindexed the table's three tags using the
> REINDEX command and packed the table's memo fields.
>
>6) I have carefully checked and rechecked the tags' key expressions.
> I have also deleted TAGS ALL and recreated each tag from scratch.
>
>
>Summary:
>None of my efforts have shed light on the problem or have restored the quicker lookup to the production data.
>
>It is like the "other" production table or .DBC has been somehow contaminated.
>This is now a production issue.
>
>I really need some fresh thoughts and insight. Any help is most appreciated!