Win7 to Win10 GPFs – solved?

Recompiling did not help – I am running source code so likely that is not
it.

Switching some of the problem code from QBE to SQL appeared to help, but
did not. I don’t think it was a memory leak as I could recreate it on one
form open, almost no activity. But probably using SQL on anything new / updated
it seems faster.

Updated BDE to latest. No change.

Set local share to false. No change.

Tried MANY other things. Hardware checks, etc.

This is a large and wide system. I started to notice other issues. A tcursor
CMAX would fail at random times, PRIV table error, table not found (they
were there), tables not found 5 times on form open then 6th time OK, etc.

This system runs on aliases and I have been diligent about always using aliases.
It has a tight layout of APPS and DATA subfolders, APPS has a dozen subfolders,
DATA has a dozen subfolders, each for each type of process / data / etc.
Each folder has dynamically created ALIAS on the app start, based on the
root.

The root is a folder on the D: Drive. This is a single PC, about five mapped
drives, all local to D:. C: is windows and programs, D: is data (I consider
“my paradox app code” data, Paradox is the application).

One of the mapped drives maps to the apps root folder on the D: drive.

I can move the root anywhere and it runs down the tree.

What struck me as odd was that it would fail in certain places every time,
but then also randomly fail, mostly table not found /  not open type errors.

I thought maybe the drive was bad, or too fast. Both WIN7 and WIN10 have
SSDs.
I changed the start root in the command line from the mapped drive to the
D: hard path, still on same drive.

The 2-3 “marker problems” I was testing for seem to go away, app was running
well. Ran large processes end to end first time no issues.

Testing and trying other things, I noted I had changed local share to false
before this start path change. I changed it back to match my start point
and match the WIN7 machine, set to true.


Sidebar:
Also, battled the dreaded virtual store BDE CFG file, having to manually
remove them from all users to get my CFG in place. I probably should hard
point to a CFG on start, but does anyone know if that command line start
virtualizes it anyway? I think virializing only happens on save, but Windows
does force apps to look there? I make BDE changes and save, then move the
CFG from the virtual store the BDE path.
I know some have installed the BDE outside the C: program files folder, that
might prevent it? I did not point to CFG on command line as it is not needed
on a single PC with one Paradox app, as they all use same CFG. But I understand
I can do that.
I don’t think that was related to my issues.


Anyway… got it all cleaned, copied the app over to fresh.
The 2-3 “marker problems” RETURNED.
UGH.
Looking back, the only change I could see was in the BDE, that I had set
local share to false, but it reverted to true in my CFG cleanup. I changed
local share back to false.

Using an icon using mapped drive as root start, errors persist.
Using an icon using hard path as root start, NO errors, so far.

My conclusion is that the combination of local share set to true and mapped
drives causes these problems on WIN10, like randomly not finding tables,
timing issues, etc.
It may be Caching? SMB?
Not sure SMB come into play with mapped drives to local folders, but it might?
Anyone have any thoughts on caching? Or details?

I have read all the arguments on local share and since almost all my apps
in Paradox are only used by Paradox (DBE) I never saw a need to change it,
it the early days it was preached set to true. But opinions vary. 

I am not sure why the combination of local share true and mapped drives used
in alias causes this? But it is repeatable. I have to icons with identical
command lines except for the start folder. And can find the error in 4 steps,
not find the error on the other.

There might be other factors, but I kept a matrix of changes to not get lost.

Research continues.