>Now this is an idea I might play around with if I can't get this worked out right. What I don't understand is why this app gets this error and my others don't (and people like you don't the error... what's different here?).
>
>Thanks for your insight.

Hi Erik,

PMFJI, but I've had this on *all* my VFP apps (especially one with many nested views) and also had the push/pop error (you probably know this but it's the C call that records the state of the registers so that a pop restores the program state and allows you to jump across code for the error handler: we had great fun with it years ago writing the Omnis error handler). It occurs for me on both my own network and on other peoples' and is easily reproducible by attempting to open the same form simultaneously. Must be my programming style (or lack of it!)

The error was being generated in the DE *BUT* I managed to prevent it by overriding my default error handler (guessing that there was then no jump across code) by using "on error e = error()" just before the DO FORM call, then having a loop with embedded DOEVENTS and random inkey() waits. Any attempt to jump to another procedure for this specific error gave the dreaded push/pop error, and any attempt to specifically check for e = 1709 failed as I got a number of different error codes once I managed to trap 1709! - in the end I just performed a retry regardless of error code and hoped for the best. RETRY was NBG so it was a hand-crafted loop. All is fine now although I occasionally have sleepless nights wondering why it works...

This probably doesn't help much - I never call openTables explicitly in code, even for NODATA views, if that's what you are doing. If you have a small sample that causes the error I'd be willing to try it on my network to reproduce it.