Know what, Tony, I tried to do exactly that at one point! I created an empty permanent table and would load the counter into the table as it went through the cursor. By checking the table I could tell which row it got to before the program quit working. I did this first in case it was stopping at the same row due to a data error. I think I tried it maybe 5 times and it always stopped at different rows within the range of a couple thousand rows or so. So I knew it wasn't a data problem. I tried putting just a "trace" in there when it reached one of the lower values of counter, but it would not bring the program up in trace mode for me, just went by as if it didn't exist... Assuming the same issue that prevented it from working also prevented it from coming up in trace mode.
Karen In a message dated 8/13/2012 5:03:27 AM Central Daylight Time, [email protected] writes: > Karen, > > > > Another possibility is to build in a counter. > > Make the counter visible and then you might be able to see how many rows > are handled by the program before it stops. > > The next step could be to incorporate the statement ‘set trace on’ when > the counter has reached a certain value. > > This procedure could provide the possibility to have a look at all > variables and other relevant thing. If the routine always stops at the same > point > you might be able to find out what causes the problem. > > > > Just an idea > > > > Tony > > > > >
