I have what is probably a VERY dumb question...but, as the name says, I am new to this. I have a search page with a drop down list of dates from which users select to search for information for that date's activities. Each record has about 100 fields in it that need to show. There are about 50 records total. Everything works fine, the user EVENTUALLY gets the results page...HOWEVER, it takes 2 maybe 3 minutes over a fast connection, for the results page to come up. Over dial-up, the user times out. The results page is also an edit page, when the user edits the information and submits it, it goes VERY FAST. Is it slow because 100 fields is too many or is it a problem with my code?:

Hi,

It will be due to the amount of fields in the layout i.e. 100 fields.

Are all of those fields needed in the web form? If not, create a new layout with only the fields necessary for the web form and link your web pages to this layout.

Ed.

THANKS...I had a hunch that was the issue - would the amount of characters in each field be an issue or just the number of fields?

100 fields, specialy if there are many relationship, calculations ..., can slow down Filemaker on the web.

So if in your page search you only need 10 field I suggest you to create a special search layout with this ten fields. It will speed up your database.

There are other parameter you can check (Ram, os version, network, CPU, your code ...)

The amount of characters could be an issue, but not normally.

For example, if you had 20 fields, all of these fields were text fields with huge amounts of text in each, then your web page would return slower than 20 fields with 1 word in each field.

I have never come accross this problem, but yes, in principal it could be an issue.

Ed.

I've tested layouts with 1000 fields.

By chance, is there some sum calculation field?

On what platform and FM version is doing that?

Hi Anatoli,

The problems I experienced in the past WAS on layouts that did contain lots of sum calculations

It also seems to be affected when there are a lot of IF calculations but this can be solved by using Case statement instead as you probably well know!

Regards

Ed.

In that case it is FM which is slowing down the WC and web serving.

Check some of my contributions in regards to transaction systems with static values vs calculations across multiple records.

Actually, there are NO calculation fields - it is PC (not MAC) and Filemaker 6.0

Hi, new! We don't use hundreds of fields but ...

(1) we noticed mysterious web waits when our search results list was too long; shortening the results list helped dramatically (we went from minutes to 1-2 seconds)

(2) we have long pauses when there's lots of content, not necessarily fields; if you cannot reduce fields, try reducing amount of non-critical content or create links to content to get it off your final page

Hope this helps!

I don't really get a results list...It searches by one field (date) and there is only one record per date...although the results page does contain all those fields - I should probably check the amount of content then? I have noticed that the Filemaker Program on the machine serving up the database and web pages sometimes stops responding while the user is doing the search (if I look at task manager)....once the results page comes up, Filemaker returns to normal. I put it out there with Instant Publishing just to see if there was a time lag, and it was QUICK...I just don't want to use Instant Publishing!

I REALLY think this is a great resource, thanks SO MUCH!

Try creating a test results page with maybe just 5 fields on it.

See what the performance is like with that. This will test for definite if the results page is the problem or if there is something else going on.

Ed.

Is that field indexed?

"A dictionary is the only place where success comes before work... "

-- not true I am very good at being lazy and successful at it

that is if u clasify being as a state of work

A few of those fields are indexed...

What happen, when you will serve page without unindexed fields? You can try that directly in FM. How fast is that?

It's been only three days so far.

I've been following this. I do not understand the problem since I tested calling a record in a db which has over 100 fields including repeating fields. Wrote a simple two page solution. No problem on localhost.

"HOWEVER, it takes 2 maybe 3 minutes over a fast connection, for the results page to come up."

So far, as best I can tell, the focus has been on the results page.

Please post your code which calls that page.

Thank you.

This is the code for the page that calls the information.

<form name="entry" action="FMPro" method="POST">

<input type=hidden name="-DB" value="Team Tools Program Guide.fp5">

<input type=hidden name="-Lay" value="TeamTools">

<input type=hidden name="-format" value="TeamToolsEdit.htm">

<select name="Date of Activity">

<option></option>

<option>06/22/2003</option>

<option>06/29/2003</option>

<option>07/06/2003</option>

<option>07/13/2003</option>

<option>07/20/2003</option>

<option>07/27/2003</option>

<option>08/03/2003</option>

<option>08/24/2003</option>

<option>08/31/2003</option>

<option>09/07/2003</option>

<option>09/14/2003</option>

<option>09/21/2003</option>

<option>09/28/2003</option>

<option>10/05/2003</option>

<option>10/12/2003</option>

<option>10/19/2003</option>

<option>10/26/2003</option>

<option>11/02/2003</option>

<option>11/09/2003</option>

<option>11/16/2003</option>

<option>11/23/2003</option>

<option>11/30/2003</option>

<option>12/07/2003</option>

<option>12/14/2003</option>

<option>12/21/2003</option>

<option>12/24/2003</option>

<option>01/04/2004</option>

</select>

<input type="submit" name="-find" value="Click Here To View The Date Selected">

Doing a search on just one field should not cause any delays in returning information. Similarly returning just one record, even with a hundred fields.

I would suggest that there are known issues with spaces in file and field names and the way that is (mis)handled through a browser.

The field name in the code is ok. You might check that all fieldnames are single or underscore_joined_words. You might try changing the db file name so it runstogether or is joined_with_underscores, and changing all appropriate references to it in your format files.

I hope this is useful.

I will give that a shot...thanks for your suggestion!

I have tried all the suggestion so far and nothing has worked...I must be making some basic rookie mistake!!!

Are all text fields indexed?

Are all calculation fields "unstored"?

Are there any portals?"

Are there any InlineActions on TeamToolsEdit.htm, the results page?

Are you serving images which are stored in containers?