No server.  Standalone PC.

Drive letters are mapped to subfolders.

>
Also you must leave Local Share true for shared paradox databases.
>
Data only used by this application. And I think that is only if shared with
non BDE applications? Anyway this is standalone PC, only this app.

I can't explain why a mapped drive letter as the start working directory
vs a non mapped drive letter path as the start working directory matters.
But I can recreate it every time.

The mapped drive is 2 folder deep on a the local hard drive. 

All other things on the PC seem to function as expected.



Plus, I have one function that works, then seconds later can't find table,
then seconds later can.
Only when the start folder and all alias are derived from a mapped drive
letter. That can't be a power setting.

I can also recreate this on other win10 standalone machines.


Leslie <"ViaThe List"@NOSPAM.com> wrote:
>Have you ensured that the Network Card on the server hosting the the 
>Mapped Drives has had power saving disabled.
>
>Also, are you using the UNC path to the mapped drive or the drive letter?
>
>To prevent virtualization of Paradox, install it outside the Program 
>Files folder maybe in the root of the C drive (on workstations).
>
>In terms of the BDE, I have provided a UAC friendly installer for BDE 
>5.2.0.2 which avoids a bunch of issues with it. Info is in the pnews BDE

>group and it has been discussed elsewhere way back as well.
>
>Lastly, since Windows 7 (I think), when a server starts to get hammered

>it now has the ability to disconnect "idle" workstations to release 
>resources. I vaguely remember a registry change to prevent this.
>
>Also you must leave Local Share true for shared paradox databases.
>
>
>On 16/06/2020 4:25 AM, Kevin Zawicki wrote:
>> 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.
>>
>
>-- 
>This email has been checked for viruses by Avast antivirus software.
>https://www.avast.com/antivirus
>