what they said, and/or tcursors.. the point is, you'll chase this forever 
and MAYBE find a combination of changes that work.. MAYBE.. just find a 
different way to do it

the dumbest thing like this, that I've seen recently.. I needed to move a 
button from one form to another.. changing where in our processes this 
certain thing is done.. no problem, copy/paste the button, change the table 
name in two places, move on.. no problems, til somebody said "can you swap 
this button for one of the ones up top?".. sure.. moving it up with some 
other buttons, changed the font on the button text, to match the other 
buttons.. BAM !!

another time, I was really changing a process, added a new "if not 
whatever()", started getting GP.. started over, moved the new "if not 
whatever()" to a different spot, no GP.. the normal process does not fall 
into the "if not whatever()" trap unless it's gonna fail, it just gets 
evaluated in a different spot in the sequence

shit happens.. like Leslie said, something leaks, that didn't before.. or 
leaks differently.. or something in the background is using a memory pointer 
differently

--

Steven Green
Myrtle Beach, South Carolina, USA

http://www.OasisTradingPost.com

Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"Kevin Zawicki"  wrote in message 
news:5ec8a68b$1@pnews.thedbcommunity.com...


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.