I have been having a problem with crashing

my webservers ability to process the OI CGI

program listed below. The webserver will still serve

pages it just won't run any oicgi.cgi. It will run

it for about a week and then start returning error

messages. This is on a pentium III with 128k and win98.

I am running my program with a link like this.

http://libertynatural.com/oicgi.exe/INET_CATLIST

It will crash the ability of both Website Pro and

the Sambar Server to process CGI programs.

Any help would be appreciated.

Roger

Here is my program.

function Inet_Catlist(Request)

$insert inet_equates

html=Content-type: text/html"

html = "

html =Customer Listing

"

OPEN ' CUSTOMERS' TO CUST ELSE PRINT 'cant open Web_Customers':STOP

OPEN 'DICT','CUSTOMERS' TO @DICT ELSE PRINT 'CANT OPEN DICT':STOP

SELECT CUST

LOOP:

READNEXT @ID  ELSE GOTO FIN

READ @RECORD FROM CUST, @ID ELSE GOTO FIN

 html ={CUSTOMER}:"

"

GOTO LOOP

FIN:

html = "

return html

R,

A couple of comments on that function. Probably nothing to do with your problem.

OPEN ' CUSTOMERS' TO CUST ELSE PRINT 'cant open Web_Customers':STOP

There's a leading space in the table name. But if it works one time it should always work.

But who do you want to tell if OPEN fails? If it's the web user you must return the error message as html, not print it on the server's printer. Perhaps it's this OPEN that for some reason fails after a while? Perhaps something happened to the table??

To return an error message to the user you can use the Inet_Msg function. E.g, do

OPEN ' CUSTOMERS' TO CUST ELSE

Message=cant open Web_Customers'

return Inet_Msg( Request, Message, , )

END

OPEN 'DICT','CUSTOMERS' TO @DICT ELSE PRINT 'CANT OPEN DICT':STOP

Same comment about error handling.

- Oystein -

Try setting the Inet_Gateway to Local Development Mode. When you get an error on the server, OI should break to the debugger and you'll be able to see where the problem is being caused.

Tim

tmarler@prosolve.co.uk @ Prosolve Software

R,

It's much easier with problems that occur consistently, and from day 1. To get a handle on your problem perhaps you could log what's happening when your function runs. My assumption is now that your function really does start to run, but then crashes or hangs.

One way you can log is to have your inet function display messages in the Inet_Gateway window. See .

- Oystein -

Tim,

Thanks for the tip from me too.

But is this good advice in all error situations? What if there's a bug in the programming - a minor one, and one that's seldom encountered, but it causes a break to the debugger. Then all execution would stop, and all users would be affected - not just one. Right? Just so I understand what it's good for and what not.

- Oystein -

While the STOP command might be the problem, seeing as how it's an invalid opcode in OpenInsight and does not compile. The print statement might cause a few issues as well.

Our past working with OICGI found that it occasionally stops responding. When this happens, you can try bringing the INET_GATEWAY to the foreground, as that has been known to restart access.

If that does not work, then rebooting the server is requied.

The Sprezzatura Group

World Leaders in all things RevSoft

Roger,

I don't know if this is the same problem or not, but we used to have a problem with our OICGI apps no longer responding after about 300 hits. This was very consistant. We finally reported it to Revelation and WinWin identified the problem with a similar one they had already resolved.

For whatever reason, Win98 OEM versions cause this problem. Check the Properties of your My Computer and see if OEM is in the registration code. If so, then this might be your problem. We switched to NT 4.0 and have not have a problem ever since.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

saw that STOP too but forgot to comment on it. but it says colon STOP not semicolon STOP. so it can't be the STOP command. must be a variable R forgot to set?

- o -

Oystein,

I use it only when developing. By the time your app goes live there won't be any bugs in the code anyway

Seriously, you will need to trap errors and handle them accordingly. I always run live apps in Runtime mode.

Tim

tmarler@prosolve.co.uk @ Prosolve Software

Tim,

By the time your app goes live there won't be any bugs in the code anyway

I blinked while reading and suddenly thought it said . How appropriate.

- Oystein -

Tim,

Btw - do you think bwg could be Welsh for [/b]bug[/b]?

Also - what do you think of the Debugger I just got up on my screen? Don't think I ever saw it in that mood before. Must have felt threatened by resources being low, and decided to put up as good a defence as it managed. Got out all its bug killing tools…

- Oystein -

View this thread on the forum...