The faster the machine, the faster memory leaks. OTOH, Paradox wasn't 
built when SSDs and superfast CPUs were thought of.

I recall an old COBOL system that all of a sudden crashed on a new 
machine. The CPU went from a 486 to a Pentium. I had to tweak the 
Motherboard to slow the CPU down. Then all was OK.

Do what Leslie said. Use local SQL. Better yet, convert to PostgreSQL.

On 23/05/2020 2:28 pm, Kevin Zawicki wrote:
> 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.
> 
> 
> 
> 
> 
>