Cetin:
Wish it were that simple.

The program in question uses SQL pass-through to do the work.
The main program contains a set-up for a varying query string within a "FOR x = 1 TO y ENDFOR" loop basically along the lines as follows:

  lcSQLQryStr = "SELECT whatever.fields, .... FROM sometable_in_the_MS_SQL2K_Database "

  lcCursorName = "CursorsName_etc" && 'cos the cursor changes for each loop in the FOR cycle.

then we call the function to process this data collection from the server
  = fGatherData(lcSQLQryStr, lcCursorName )

The function 'fGatherData' handles the connection handle, SQLPrepare and SQLEXEC, etc.,

This approach is exactly as also used in many other programs without ever any problem whatsoever. But in this case, once in the Debugger, you can step through the trace from start once only untill you come to the call to the function and then the trace is no longer sequentially displayed - it just stops at this line and the 'Next Statement' arrow in the left margin STAYS on the the first line of the function which reads:

   ===> FUNCTION fGatherData - perfectly conventional.

Meanwhile, if you choose 'RESUME' the program itself then continues to execute all parts of the associated processing in the overall program but the debugger will not "STEP' through or past this line and, while still in the FUNCTION area, you cannot even choose to 'SET NEXT STATEMENT' from a RIGHT CLICK but if you choose 'RUN TO CURSOR' the program continues execution without the trace steps being displayed until coming back around on the next loop to the beginning 'lcSQLQryStr' statement in the main program area where it then stops. Now you can step once more until the program again reachs the call to this function and once more freezes the trace there.

As I said in my original post - this effect is seen in both VFP8 & 9 and on different workstations, 1 running Windows 2K Professional with a 1GHz, P4 processor and 500MB RAM, the other running Windows XP SP1 with a 3.2GHz P4 hyperthreading processor and 1 G RAM.

Go figure: Why this program has problems and others using same approach to data processing has no problem. Really need an answer as there is a bug in the truculant program ~ <grin> Maybe the bug is the cause of this behaviour but how does one establish that as a fact when you cannot use the debugger to expose it?

Hope that helps explains the situation? Thnx for attempting an answer.
- BTW: Your help has been right on many times in past years dealing with interfacing to XL. Thnx. /psb