Recent Posts
11
ODBC / ODBC Service Crashing
« Last post by Jeffrey Ferreira on April 12, 2024, 08:09:26 AM »Hello All,
I have a customer who uses ODBC a lot to access their pxplus files. We have service crashes quite often.
I'm assuming the first thing we should do is update their ODBC Version but before we do that, is their anything that could possibly be going on
thanks
jeff
Error Message:
Faulting application name: pxpiosvr.exe, version: 5.20.0.0, time stamp: 0x51815515
Faulting module name: ntdll.dll, version: 10.0.14393.6343, time stamp: 0x6502749b
Exception code: 0xc0000005
Fault offset: 0x000587a9
Faulting process id: 0x8d2c
Faulting application start time: 0x01da8ccff7520e30
Faulting application path: C:\PVX Plus Technologies\File Server\pxpiosvr.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: e605ac47-8a76-4ee5-abcb-93544bd6bc91
Faulting package full name:
Faulting package-relative application ID:
I have a customer who uses ODBC a lot to access their pxplus files. We have service crashes quite often.
I'm assuming the first thing we should do is update their ODBC Version but before we do that, is their anything that could possibly be going on
thanks
jeff
Error Message:
Faulting application name: pxpiosvr.exe, version: 5.20.0.0, time stamp: 0x51815515
Faulting module name: ntdll.dll, version: 10.0.14393.6343, time stamp: 0x6502749b
Exception code: 0xc0000005
Fault offset: 0x000587a9
Faulting process id: 0x8d2c
Faulting application start time: 0x01da8ccff7520e30
Faulting application path: C:\PVX Plus Technologies\File Server\pxpiosvr.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: e605ac47-8a76-4ee5-abcb-93544bd6bc91
Faulting package full name:
Faulting package-relative application ID:
12
Wish List / Re: An updated Eclipse Plugin
« Last post by mgoeijen on April 12, 2024, 04:34:55 AM »The Sage plugin does not work anymore. I get the following error message:
Unable to read repository at https://eclipse.sagemas.com/content.xml.
Is there anyone who can solve this?
Unable to read repository at https://eclipse.sagemas.com/content.xml.
Is there anyone who can solve this?
13
Nomads / Re: Panel Startup Timing
« Last post by James Zukowski on April 09, 2024, 02:19:19 PM »Mike:
The timed trace was a great insight. It looks like each WindX transaction averages about 0.045 seconds on our network. So if I'm grabbing a property from 2 controls in 1 LET statement, or get one and set another, for example, that's 2 transactions, or about .09 seconds. MSE and obj(0) seem to be 0.09 each, etc.
The old panels had been set up as Resizable/Auto-Size. This caused multiple transactions per control once they were first drawn to see if they needed to be changed (which they didn't).
I reset these to Resizable/Custom and set appropriate anchor points for each control. This took a launch time of about 6.5 seconds down to less than 1.5.
Thanks for the help! GREATLY appreciated.
P.S.: We didn't do anything with Turbo Mode. If NOMADS did, then that's another story.
P.P.S.: Still haven't figured out why SPAWNing always worked so fast. There are bigger fish to fry at this point, and they'll all eventually go away, so it will be a moot point soon.
The timed trace was a great insight. It looks like each WindX transaction averages about 0.045 seconds on our network. So if I'm grabbing a property from 2 controls in 1 LET statement, or get one and set another, for example, that's 2 transactions, or about .09 seconds. MSE and obj(0) seem to be 0.09 each, etc.
The old panels had been set up as Resizable/Auto-Size. This caused multiple transactions per control once they were first drawn to see if they needed to be changed (which they didn't).
I reset these to Resizable/Custom and set appropriate anchor points for each control. This took a launch time of about 6.5 seconds down to less than 1.5.
Thanks for the help! GREATLY appreciated.
P.S.: We didn't do anything with Turbo Mode. If NOMADS did, then that's another story.
P.P.S.: Still haven't figured out why SPAWNing always worked so fast. There are bigger fish to fry at this point, and they'll all eventually go away, so it will be a moot point soon.
14
Nomads / Re: Panel Startup Timing
« Last post by Mike King on April 06, 2024, 12:59:55 PM »It sure sounds like there is something wrong with your setup. The PROCESS definitely should run faster than a spawn.
One difference between the PROCESS vs spawn is that with the spawn you are starting from a clean environment whereas the PROCESS will inherit the environment from the menu.
I would suggest you try enabling a timed trace on the PROCESS to see what might be causing the issue.
I might also make sure you aren't doing anything such as turning off turbo mode which would also explain the fact that general performance seems to be suffering when using PROCESS.
One difference between the PROCESS vs spawn is that with the spawn you are starting from a clean environment whereas the PROCESS will inherit the environment from the menu.
I would suggest you try enabling a timed trace on the PROCESS to see what might be causing the issue.
I might also make sure you aren't doing anything such as turning off turbo mode which would also explain the fact that general performance seems to be suffering when using PROCESS.
15
Nomads / Re: Panel Startup Timing
« Last post by James Zukowski on April 05, 2024, 04:33:22 PM »Another observation: Tabbing from field to field also takes a LOT of time, even on the test server, which has VERY few users. The server utilization theory fails there...
16
Nomads / Re: Panel Startup Timing
« Last post by James Zukowski on April 05, 2024, 03:14:03 PM »I thought SPAWNing would take more time, too. I ran a brief test on our test server, and the first time I ran the panel, it came up in about 2 seconds. Exiting back to the menu and starting again took about 8 seconds, which remained consistent in subsequent runs. So...why would the first run launch so quickly and the others not? It doesn't make sense to me.
If we scrapped the show(-1) method, what would be the 'best' method to hide the menu? Move it WAAY off the screen, and move it back later? Something else? It seems like with Win 11 (or earlier), we've lost the ability to right-click an icon on the taskbar and move the window with the arrow keys, so shifting off-screen is a concern.
If we scrapped the show(-1) method, what would be the 'best' method to hide the menu? Move it WAAY off the screen, and move it back later? Something else? It seems like with Win 11 (or earlier), we've lost the ability to right-click an icon on the taskbar and move the window with the arrow keys, so shifting off-screen is a concern.
17
Nomads / Re: Panel Startup Timing
« Last post by Mike King on April 05, 2024, 02:08:48 PM »A PROCESS directive should take less time than spawning. Perhaps the SHOW(-1) is causing a issue?
18
Webster Plus / Re: Webster 101: Web for dummies
« Last post by Mike King on April 05, 2024, 01:58:28 PM »Jean,
I'm away at the moment, but I will contact you next week with some tips/ideas on how to get started.
I'm away at the moment, but I will contact you next week with some tips/ideas on how to get started.
19
Nomads / Re: Panel Startup Timing
« Last post by James Zukowski on April 05, 2024, 01:51:37 PM »(Un)Fortunately, there are only about 30-40 left to remove the SPAWNing from, and we're developing all new panels without it; they're directly PROCESSed. They also seem to take a fair amount of launch time.
Is there anything I could look into?
Is there anything I could look into?
20
Nomads / Re: Panel Startup Timing
« Last post by Mike King on April 05, 2024, 01:33:36 PM »The easiest solution might be to just dynamically define unique FID values for every process. You can then use the SETFID directive to set the session FID value.
FID(0) values can be up to 12 characters long -- assuming your code will accept that length.
There are any number of ways you could generate the FID values perhaps using a specific range for each workstation and a control file where you can lock records to assure uniqueness of FID.
In theory you might be able use the process ID as a FID(0) value which would assure uniqueness.
FID(0) values can be up to 12 characters long -- assuming your code will accept that length.
There are any number of ways you could generate the FID values perhaps using a specific range for each workstation and a control file where you can lock records to assure uniqueness of FID.
In theory you might be able use the process ID as a FID(0) value which would assure uniqueness.