Several years ago I stopped compiling my apps to machine code, and instead distributed them as interpreted code, which compiled quicker and performed better. I am currently on 10.5 with latest available build. Recently I added less than a dozen lines of code to resolve an issue, and several users were unable to launch the application. I had seen this previously, and found if I created an additional pbl, and moved several objects from an existing pbl to the new one, in effect making the sizes of a large pbd smaller, that the user would be able to launch the application. No error messages are being issued, the application was just not launching, so I suspected a memory issue on these isolated user PCs. Yesterday morning I had 3 such issues, I reduced the largest pbd to below 500 kb and the users were then OK. Today more users reported the problem. I lowered the maximum pbd size below 400 kb, but that didn't help. After trying several things, I recompiled the same application as machine code. Each user that reported a problem was then able to launch the application. The size of the DLLs in the machine code were larger than their corresponding pbds, so that blew away the size theory. Can anyone explain what might be going on in this scenario. Users and development done on XP SP3.
> Several years ago I stopped compiling my apps to machine code, and > instead distributed them as interpreted code, which compiled quicker > and performed better. I am currently on 10.5 with latest available > build. Recently I added less than a dozen lines of code to resolve an > issue, and several users were unable to launch the application. I had > seen this previously, and found if I created an additional pbl, and > moved several objects from an existing pbl to the new one, in effect > making the sizes of a large pbd smaller, that the user would be able > to launch the application. No error messages are being issued, the > application was just not launching, so I suspected a memory issue on > these isolated user PCs. Yesterday morning I had 3 such issues, I > reduced the largest pbd to below 500 kb and the users were then OK. > Today more users reported the problem. I lowered the maximum pbd size > below 400 kb, but that didn't help. After trying several things, I > recompiled the same application as machine code. Each user that > reported a problem was then able to launch the application. The size > of the DLLs in the machine code were larger than their corresponding > pbds, so that blew away the size theory. Can anyone explain what > might be going on in this scenario. Users and development done on XP > SP3.
It probably has nothing to do with the size, but perhaps with the ancestry of your classes and how you build the application.
Sometimes a class will fail to compile but you can still build the exe and pbd's.
Or it could be related to the versions of pb dll's on the client machine.
> Several years ago I stopped compiling my apps to machine code, and > instead distributed them as interpreted code, which compiled quicker > and performed better. I am currently on 10.5 with latest available > build. Recently I added less than a dozen lines of code to resolve an > issue, and several users were unable to launch the application. I had > seen this previously, and found if I created an additional pbl, and > moved several objects from an existing pbl to the new one, in effect > making the sizes of a large pbd smaller, that the user would be able > to launch the application. No error messages are being issued, the > application was just not launching, so I suspected a memory issue on > these isolated user PCs. Yesterday morning I had 3 such issues, I > reduced the largest pbd to below 500 kb and the users were then OK. > Today more users reported the problem. I lowered the maximum pbd size > below 400 kb, but that didn't help. After trying several things, I > recompiled the same application as machine code. Each user that > reported a problem was then able to launch the application. The size > of the DLLs in the machine code were larger than their corresponding > pbds, so that blew away the size theory. Can anyone explain what > might be going on in this scenario. Users and development done on XP > SP3.
I suspect you are doing incremental builds. Switch to FULL builds.
> On Jun 16, 5:14 pm, waldonj <b...@boblandau.com> wrote:
> > Several years ago I stopped compiling my apps to machine code, and > > instead distributed them as interpreted code, which compiled quicker > > and performed better. I am currently on 10.5 with latest available > > build. Recently I added less than a dozen lines of code to resolve an > > issue, and several users were unable to launch the application. I had > > seen this previously, and found if I created an additional pbl, and > > moved several objects from an existing pbl to the new one, in effect > > making the sizes of a large pbd smaller, that the user would be able > > to launch the application. No error messages are being issued, the > > application was just not launching, so I suspected a memory issue on > > these isolated user PCs. Yesterday morning I had 3 such issues, I > > reduced the largest pbd to below 500 kb and the users were then OK. > > Today more users reported the problem. I lowered the maximum pbd size > > below 400 kb, but that didn't help. After trying several things, I > > recompiled the same application as machine code. Each user that > > reported a problem was then able to launch the application. The size > > of the DLLs in the machine code were larger than their corresponding > > pbds, so that blew away the size theory. Can anyone explain what > > might be going on in this scenario. Users and development done on XP > > SP3.
> I suspect you are doing incremental builds. Switch to FULL builds.- Hide quoted text -
> - Show quoted text -
I always do full builds. In fact when I first switched to interpreted deployments, part of it was due to the extremely long compilations of my larger applications into machine code.
> On Jun 17, 9:43 am, Rich Frantz <richfra...@gmail.com> wrote:
> > On Jun 16, 5:14 pm, waldonj <b...@boblandau.com> wrote:
> > > Several years ago I stopped compiling my apps to machine code, and > > > instead distributed them as interpreted code, which compiled quicker > > > and performed better. I am currently on 10.5 with latest available > > > build. Recently I added less than a dozen lines of code to resolve an > > > issue, and several users were unable to launch the application. I had > > > seen this previously, and found if I created an additional pbl, and > > > moved several objects from an existing pbl to the new one, in effect > > > making the sizes of a large pbd smaller, that the user would be able > > > to launch the application. No error messages are being issued, the > > > application was just not launching, so I suspected a memory issue on > > > these isolated user PCs. Yesterday morning I had 3 such issues, I > > > reduced the largest pbd to below 500 kb and the users were then OK. > > > Today more users reported the problem. I lowered the maximum pbd size > > > below 400 kb, but that didn't help. After trying several things, I > > > recompiled the same application as machine code. Each user that > > > reported a problem was then able to launch the application. The size > > > of the DLLs in the machine code were larger than their corresponding > > > pbds, so that blew away the size theory. Can anyone explain what > > > might be going on in this scenario. Users and development done on XP > > > SP3.
> > I suspect you are doing incremental builds. Switch to FULL builds.- Hide quoted text -
> > - Show quoted text -
> I always do full builds. In fact when I first switched to interpreted > deployments, part of it was due to the extremely long compilations of > my larger applications into machine code.- Hide quoted text -
> - Show quoted text -
I work on an enterprise PB system with many PBD's some of which are larger than 10MB. How can you be sure that your system is not crashing silently? If you can reproduce what your users get then try build your app with the PBD option and run your EXE with the "/pbdebug" flag then inspect the generated file from bottom upwards to see why it crashed - which object was last accessed... I've seen our system suddenly disappear without any error messages (or GPF's) which usually relates to recent changes that corrupt memory locations. BTW, what were the latest changes that you made - do you use any dynamic calls etc... cheers H
