There is a known bug within the BDE which occurs when QBE query results 
are generated.

Ultimately what occurs is a memory walk which can then affect an 
application (mine was C++) later on in the execution process.

To be clear the memory walk always occurs regardless of operating system 
etc. However, that bug may or may not cause your application to fail 
depending upon memory configuration etc. Thus it appears to be random 
almost.

Our first solution was to spawn a separate process to perform the QBE 
and generate a results table. This worked but was a hack at best.

Our second solution which remains in place was to replace the QBE with a 
Local SQL query. In fact we decided to replace all QBE's with Local SQL 
Queries as they are now native to the BDE whereas QBE's are 
converted/translated to SQL internally now (faded memory here).
All of our memory walks went away once that was done.

So I suggest you replace the QBE with a local SQL query and see what 
happens, its the preferred thing to do anyway since BDE 5.2.0.2

my 2 cents
Leslie.


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.
>
>
>
>
>
>

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus