Hi all,

I am modifying some existing code that my company uses on a daily basis. It entails processing information from many separate free tables. At a particular point within the process, the program needs to be suspended / cancelled so that one of the tables can be manually edited. Afterwards, the program needs to resume from where it left off.

As it stands now, the users of this program have been cancelling the main program, sending the file to the appropriate department for cleaning and then, upon return, making a copy of it, restarting the main program from the beginning and at the SUSPEND, recopying the cleaned table back into the proper directory in order to RESUME processing.

It was my hope to be able to bypass this way of processing by taking a snapshot of the data session with CREATE VIEW (filename) and SAVE TO (filename) in order to be able to restore the data session and all memory variable created up to the point of SUSPEND. With additional coding at the beginning of the main program to ask the user if it is the first time through and if not, bypass the code up to the point of SUSPEND.

This technique is working, but not fully. That is, of the dozen or so tables that are open in the data session at the time of CREATE VIEW, all but one reopen correctly with SET VIEW TO. This one file, at the point of CREATE VIEW is indexed, however, when reestablished with SET VIEW TO, it opens without it being indexed. As stated this is the only file. All others reopen with their indexes set properly.

This particular table resides in work area one (1). I have used the debugger to trace any activity that this table goes through without finding any cause for it not to be reopened correctly. I have taken snapshots programmatically as well as manually, with the data session open to insure that the file, prior to CREATE VIEW is being used with it's index set, so I know that it is as it should be. However, the ensuing SET VIEW TO always results in this one table not reopening indexed.

There are no relationships set that involve the table. All it is used for is to determine if matching entries exist within other tables. This is determined via SEEK(). Of course, I could force the file to be indexed upon reopening it with SET ORDER TO indexname in tablename, but I shouldn't need to.

If anyone has any idea as to why a table would not reopen as it was when CREATE VIEW was issued, I would be grateful to hear about it. As stated this particular table resides in workarea one (1). Other than that, there is nothing unusual with it.

Additionally, I have opened the table (indexed) by itself outside of the main program, issued CREATE VIEW, closed VFP, restarted VFP, issued SET VIEW TO and the table has reopened as it should, indexed properly. But for the life of me, I cannot understand why it fails replicate this behavior when run from the main program.

Again, any ideas would be helpful.

Thanks
Vince Tomazzolli