Subject: | =?UTF-8?Q?Re:_Win7_to_Win10_GPFs_=e2=80=93_solved=3f?=
| Date: | Tue, 16 Jun 2020 14:21:20 +1000
| From: | Leslie <"ViaThe List"@NOSPAM.com>
| Newsgroups: | pnews.paradox-development
|
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
|