Starting a new thread.


I am aware of the size limitations, I don't come close to them in LIB size
or methods. 


Plus, as I said it runs fine in WIN7 and fails in same places on two different
WIN10 machines, one a well tested PDOX install used in my "DEV LAB" and one
(brand new WIN10) machine.

This form calls several libraries in other places, but the points of failure
are simple queries in procs and methods in the form itself. Fails on QBE
execute. Not in the libs. PLUS the procs that fail are called on form open
(before default) and run fine.

If I have the form open and running and run a piece of the code that fails
from a script or other form interactively. Go back to the form, count to
3 and it blinks out Paradox.


If I cut out the queries and run them outside the form the queries run fine.
Rebuilt tables from scratch. Removed indexes not used here in this form.
The tables are small.

This is really centered on a certain table that is in the tableframe and
a query updates it. As if it either GPFS or simply closes on data changes
to the table under the table frame.

The tableframe is on a tab.

Stripped down the form to nothing but what is needed for this error and same
see error.

It might be corruption, but retrieving the entire system from archive from
2013, 2014, 2017 - all show same error only in WIN10.

This new PC is much faster, but the DEV LAB one is use for many PDOX systems
and support is not as fast.

The DEV LAB PC has probably over 20 active systems from different shops.
If it was a PDOX install of config issue I think I would have seen it before
this.

Moving on to other parts of this system I just PROD parallel another large
process that uses tcursors, queries, textStreams, GUI, etc. 

It's a large import process and setup  - I ran it and thought it failed,
but in ran in about 10 seconds on the new WIN10 machine instead of 4 minutes
on the WIN7 machine. No other parts of  testing have this issue, there are
about 10-12 modules.

I am stumped. I am doing something allowed in PDOX compile, that WIN7 has
no issues with and WIN10 GPFs.

I am also testing delayscreenupdates, but I would have to add them almost
everywhere, plus have other modules that do very similar things with no issues.

I also tried cut and paste some parts of it to new form. But there is much
that is needed to get it to work at a minimum.
I have always heard you can cut and past a corrupt object so do not want
to chance it.
Plus this corruption would have to have there for the last 10 years. When
going back the form was much simpler the farther I go back and the error
persists.


I am creating a new form, lib, process from scratch. Maybe cleanup up the
process better integrating the newer items added, etc. If I add things re-coded
back in and hit this error I may find out why.

But it is critical and actually complex coding built around business processes,
evolved over time. I will have to rethink it.

"management is not happy about a long delay to new machine" but understands
this is a 30 year system brought up as business evolved and Paradox evolved.