The problem is related to the following line:
DIMENSION laP21SheetOut[2020,12]
The FoxWeb error handler uses the command LIST MEMORY TO FILE to get a list of all active variables, so that it can log them. Once it reads the file, it processes it line by line to correct wrapping problems. This is because the output of the list memory command is typically created for display on screen, so VFP wraps long lines in this file.
It seems that the code that processes the file is not very efficient, and takes too long to run. In this particular case, the resulting file is almost 25,000 lines long. As the error handler steps through the file and adds each line to a variable that is eventually going to be copied to the error log, the variable becomes bigger and bigger. After a certain size, string concatenations in VFP become too slow.
We will make sure to fix this problem in the next release of the software.
FoxWeb Support Team
support@foxweb.com email |
Sent by Bret Hobbs on 01/21/2003 10:58:22 AM:
I isolated the no reporting of errors to the following code:
*****
* Begin P21 Creation
* P21s are created for every DODIC/NALC on the P5A
* it consists of 2 sheets (sheet 1 1st three years starting
* with FY of Month Year input, sheet 2 next three years
*
LOCAL lnP21Index, lcP21NalcSave, lcP21Nalc, lnNalcAdminLeadTime, ;
lnNalcProdLeadTime, lnNalcTotalLeadTime, lcManufactureUsed
lnP21Index = 0
lnNalcAdminLeadTime = 0
lnNalcProdLeadTime = 0
lnNalcTotalLeadTime = 0
lcP21NalcSave = ''
lcManufactureUsed = ''
lnManufExcelRow = 0
LOCAL lnP21MinProdRate, lnP21185ProdRate, lnP21MaxProdRate
lnP21MinProdRate = 0
lnP21185ProdRate = 0
lnP21MaxProdRate = 0
LOCAL laP21SheetOut, lnAccPriorQty, lnLaterQty, lnBalanceDueQty
DIMENSION laP21SheetOut[2020,12]
lnAccPriorQty = 0
lnLaterQty = 0
lnBalanceDueQty = 0
***** |
The error reporting works before the code above, but ceases sometime inside the code. I can see nothing wrong with the code, as it works using 1.29. Can you see anything, such as if I am using a variable that 2.11 uses in its reporting?
Bret
Sent by FoxWeb Support on 01/21/2003 10:12:36 AM:
The best way to find out what is happening in this case is to debug your program, using one of the techniques described in the FoxWeb documentation. You can use the VFP debugger, or you can try moving the line that causes the "Operator/operand type mismatch" error progressively down your program until the problem occurs. This will help you isolate the code that causes the change in behavior.
FoxWeb Support Team
support@foxweb.com email |
Sent by Bret Hobbs on 01/21/2003 05:05:24 AM:
I placed your code at the start of the prg and received the following in my web browser:
***************
There was an error during the interpretation of your request.
Error #: 107
Message: Operator/operand type mismatch.
Program: GENERATEEXHIBIT C:\PROGRAM FILES\FOXWEB\PROGRAMS\WEBBUDGETANALYSIS\WEBBA.FXP
Line #: 156
Line: a = 1 + .T.
******************
Which worked fine, but when I placd your code deeper in my program where the timeout issue occured. Then there was not display of an error message, just the timeout warning.
I will let you interpret what that means or what is causing the suppression of your error reporting back to the browser. If you would like me to send you the prg. I will be more than happy to do it. It wont work for you as the files will not be in place where you are, but at least you can see where it is happening.
Bret
**
Sent by FoxWeb Support on 01/17/2003 04:19:26 PM:
Does error reporting fail for all errors, or just this one? What if you add the following line in one of your scripts?
a = 1 + .T.
If this error also fails to be handled properly, then there may be something wrong with the error log. Try deleting the files errors.dbf, cdx and fpt. Another possibility is that you have specified your own error template in the FoxWeb Control Center, but this file does not exist, has not been compiled, or contains an error in it. Remember that VFP cannot report errors within an error handler.
FoxWeb Support Team
support@foxweb.com email |
Sent by Bret Hobbs on 01/17/2003 04:52:38 AM:
The Run as Service has always been unchecked.
I Unchecked Hide windows.
I edited the code to put back the error condition, which is a line like:
IF NOT EMPTY(FILETOSTR(lcPssErrorFileFullPath))
where the file referenced in lcPssErrorFileFullPath was never created. The develper box running 1.29 showed this error on the web page and the line it occured at, but the 2.11 version just timed out.
So after I changed the above code back to the bug I ran the Web App.
I looked at the FoxWeb channels and FoxWeb1 Channel showed busy.
I looked at the window and it showed some text about the server and no pop-up windos showed up at all.
I waited and the Web App timed out like was reported and the FoxWeb1 channel went from busy to waiting.
I am running the FoxWeb 2.11 version on a Win 2000 Server box. FoxWeb has a 2 server license running also.
Any thing else you need just ask.
Bret
Sent by FoxWeb Support on 01/17/2003 12:52:51 AM:
The timeout probably occurs because something in your code causes the FoxWeb channel to pop up a dialog, asking for user input. To verify this, disable the Run as Service and Hide Channels options and restart FoxWeb. Open the channel windows and arrange them on your screen, so that you can see them all at the same time. Now call your script and see if a window pops up.
I don't know why the two versions would behave differently, but if this is a different server, it is possible that FoxWeb can simply not find a particular table on your 2.11 server.
FoxWeb Support Team
support@foxweb.com email |
Sent by Bret Hobbs on 01/16/2003 10:39:23 AM:
We have installed the new FoxWeb version 2.11 using our existing 1.29 Code (option set). We will be converting our 1.29 code over as time permits. But the new server using FoxWeb 2.11 has been timing out on us today. When I went back to our developer server (which still uses 1.29) and ran the code. It reported a bug in a section of my code, that was never reached during our initial testing. I then edited the code and it fixed the bug on the developer machine. The 2.11 machine never reported the error it just reported a time-out error (because it past the Time-Out setting). So if I never had the developer server with 1.29 still on it I would not have found the error without some major debugging time.
My question is when running old 1.29 code on the 2.11 version is there a setting that will get FoxWeb to report errors back as 1.29 did and not just time out?
Thanks
The early bird may get the worm, but the second mouse gets the
cheese.