It seems that the proceedure I am using to populate a web page is limited to 64K.

I would appreciate some input on other ways that would allow me to exceed the 64K limit.

The submit method is…

   "/cgi-bin/oicgi.exe/inet_oicgi"

"INET_OICGI" is a stored procedure that builds the results and then returns the produced html document.

One of my web pages allows the user to view customer activity. Since the user can enter the "direct" customer code, or use a word lookup. If the user does the word lookup, it is possible to have a result of hundreds of customers to select from. By the time you display the name, address, etc.; You could have well over 64k of data.

Since the stored proceedure returns the result (RETURN HTML), it is limited to 64k.

Richard,

1. One way of circumventing the limit is to show the result in chunks, like most search sites do. But a bit of programming is needed.

2. Another way is to write the result to a file - an html file - in the web server's document folder, and return to the user a different document whose only purpose is to redirect to the first document.

3. I think Sprezzatura's S/Web allows large documents.

4. And presumably the announced 32-bit OI will too.

- Oystein -

32-bit OI has a real limit of about 2 Gig.

Mike

Ahhhh… never thought that way. Very good!

Hmmmm… The redirect must be delayed until the "OSBWRITE" is completed.

I think I can do that. If I Create the "result" page as a redirect to itself every 1 second. That way the "OSBWRITE" can overwrite the redirect. HA! bet that will work.

Thanks for the insight!

Yea and I can't wait for the 32-bit version.

Or… do I have to wait??? Is it available now?

Not yet- figure Mid-February or so….

Richard,

The redirect thing has been discussed on the lists. Might have been Sprezzatura that came up with it. Never tried it myself. I've used alternative 1 myself.

- Oystein -

Unless you're working on an Intranet, you might consider staying away from large pages anyway due to the download time. All very well being able to create a 2GB page with lots of info on, but 'good web practice', whatever that means these days, indicates that all web pages should be below 50K, until everybody is on Broadband :)

I agree with Oystein and go with option 1, if you run long reports you might start 'hanging' your webserver, remember OI is single threaded (lest we all forget!)

But perhaps there's a middle ground. Make several documents with links between them, and redirect to the first of them. Just an idea.

- Oystein -

I definately appreciate all your input. It surely opens my eyes. I agree with the quantity discussion. Its just that very few times a query will take greater than 64k, and I have to be prepared for that.

Almost 95% of the resulting web pages are very small. Its that 5% that might exceed the 64k boundry.

Also, most likely the 5% that exceeds will be on an inTRAnet.

You all were very informative; thanks.

Richard,

If I understand correctly, you do a selection/lookup process and get a variable number of keys back, with which you can create a list.

We have a similar situation: in most cases we get a relatively small list, but we also have to provide for exceptions.

We use inet_rlist() to display the key and a symbolic dictionary item with embedded HTML/JAVASCRIPT code, which summarizes the info and allows the user to "zoom in" to look at the complete record by clicking on the key.

Inet_rlist handles unlimited number of records through paging. So, if your individual page does not exceed 64K barrier you shouldn't have any problem at all.

You just have to dimension page size (records per page) and the maximum record display size (plus allowance for HTML overhead) within 64K and leave the rest to inet_rlist.

Hope this helps.

Wilhelm

View this thread on the forum...