My database is quite complex and comprehensive. I have 136 fields and IE will not process this many form fields appearently. In Netscape, the form submits fine, but in IE nothing happens when submit is hit or the "RETURN" key is used. The "list all" option still works fine. I eleminated all but 92 (+ the 10 search options, uid, and db fields) and IE worked fine again. I can only assume that IE has a max form fields of 104.

As I only have NS and IE availible to me currently, I can only imagine what would happen in older or less robust browsers.

Anybody have any suggestions!

Troubleshooting Steps taken so far:

Proofread 4550 lines of code in html.pl - No Help!
Tried autogenerate - No Help!
Added "/n" to sub build_select_field lines (from forum) - No Help!
Used very simple table for form with fewest options
selected, no tabs, .... - No Help!

Conclusion:
HTML is sound.
IE has limitation of 104 form fields while NS does not.
beetleman

Marcus L. Griswold

Does it work with 103 fields? What about 105 fields?

It sounds almost like a syntax problem (bad html tag, etc), but IE is a *lot more* tolerant of bad markup than Netscape - so I'd almost expect it to be the other way around.

I have a db that has over 150 input fields, plus quite a few hidden input fields (50 or more) and I haven't experienced any problems using IE.

Sorry I couldn't be of more help.

My thinking was it was the overall legth of the submitted URL, and not the number of fields, thus shorter field names might help?

Sorry I don't have a more definite answer.

I had the same problem with a database where I had about 150 fields, most of which were select fields.

I was able to run it fine even in Netscape 3.0 or above, but IE had major problems with memory issues.

I think perhaps because IE itself may be memory intensive and therefore running a large database adds to the problems.

It worked fine if I cleared the cache and made sure no other programs were running (freeing more memory) and then reloaded the page. Since it only caused problems with IE I came to the conclusion it was a memory issue more than a problem with the amount of fields being displayed.

Hope this provides some insight.

Unoffical DBMan FAQ

http://creativecomputingweb.com/dbman/index.shtml/

Watts,
103 and below is fine.105 and above is bad.

LoisC,
You could be very right about the memory limitations in IE. The DB is set up on my laptop running a virtual (developmental) server. (Just couldn't convince my wife that paying for a server during 6 mo. of devlopment was a good idea.)

The issue for me now is user conveinience. If the DB doesn't work on the first ten or so clicks, the user will lose interest.
The search forms are the problems...
GET-method forms don't work but the POST-method forms do work.

Obviously, users will not be able to search via 136 fields nor would they want to. Many fields are relational to each other.

i.e.
Number_Availible_Colors => [ 1
Mutliple_Colors_Availible => [ 2
So if N_A_C == 0 --> M_C_A = "No"

etc. ...

via javaScript of course.

As a result only one of these would need to be searched.

So, that sidesteps the IE problem, but I am hoping for a solution that relies less on limiting options.

Will try to shorten field names as well.

Any more ideas?

It may not be a popular opinion, but its the only one I have.
beetleman

Marcus L. Griswold

Further Update to Situation:

After some trial and error, I have found that IE will only accept an HTML URL length of 2047 characters. Or one less than 2 K.

At that rate, with 148 fields (including search options, uid, db fields), the average character count for the field name and value is 13.8 minus "&" and "=".

That's 5 letters for name and 6 letters for value.
&12345=678901

Even by using shorter field names, I may not be able to fit all of the data into the resulting URL string sent to the server.

As stated before, the limitation only applies to the form method="GET" and not the "POST".

So new or modified information is not effected but the search option has limitations. Unfortunatly, (as we all know) the search option is most used by guests which are impatient while users would be less effected.

Aside from limiting the number of fields to be searched and shortening field names, does anybody have any other ideas?

Thanks in advance.
beetleman

Marcus L. Griswold

Maybe let the user POST the URL for the search, build a sub that grabs the posted string and eliminates and empty search fields, and then prepares and returns a new URL string and a submit button, thus the user has to submit twice.

Perhaps the modified string could be sent to the search sub without the second submit, or the second submit could be a timed META refresh or something.

This does not help if the field names or values are still VERY long, or if the user searches in lots of fields.

Also seems like java could eliminate fields for which no search value was specified. Thus shortening the search.

Perhaps java could eliminate fields without values from the search string AND check the overall length, then tell the user not to search for so many things if the string was too long?

You could combine several fields into keyword groups which would search several fields, yet only require the user to specify the value once.

Example:
&outerwear=blue

would repalce
&coats=blue&shirts=blue&pants=blue&sweaters=blue

and at the same time not find records with only blue underwear or socks.