Subject: | Re: WIN10 GPFs not on WIN7
| Date: | Sat, 23 May 2020 18:54:38 +1000
| From: | Tom Krieg <REMOVEtomkCAPITALS@sdassociates.com.au>
| Newsgroups: | pnews.paradox-programming
|
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.
>
>
>
>
>
>
|