(Sigh) Yeah I think that's what I'm going to have to do but I don't like it. I still don't know why VFP gives me an error with my handler and not its own. And what other errors are lurking out there that will set it off. Oh well, thanks for the input John!

>Hmmm...not impossible but tricky. First off, you'd have to have a generic Fox DSN which you probably already have. Then you'd want to use the CREATE CONNECTION command to create a custom connection. This requires exclusive use of the database container (DBC). Then you'd want to CREATE SQL VIEW {alias} to create a view and always give it the same alias name (that way your bound data stays OK). Then you'd have to issue some DBSETPROPS to make sure your keyfield was identified and updatable.....Finally, you'd want to DELETE CONNECTION on exit to clean up (this also requires exclusive use of DBC).
>
>So...back to the top issue:
>
>Why not just trap for this specific error and force an ignore?
>
>
>>That sounds like a good idea but my problem is that I have no idea what the 2.6 tables are called until runtime. The names of the tables are pulled from a different source. I know how to set up an ODBC View through VFP but I'm not sure how to do it at runtime through code so that I can plug in the table names and establish the connection while the exe is running. How difficult is that to do?
>>
>>
>>>OK, Kevin, how about grabbing the table through a remote view, using an ODBC connection?
>>>
>>>
>>>>Yeah I know, that's what has me baffled too! It's a little involved to explain but the table I open is in a zipped file that is unzipped EVERYTIME before it is used. So the table is ALWAYS clean when I USE it. It is a 2.6 table but I'm not opening it exclusively so VFP doesn't try to convert it. The thing is that if I don't use ON ERROR, VFP opens the table with no complaints but if I do use an ON ERROR DO FORM it complains about not being able to find the CDX!
>>>>