search in browser, client stays in find mode

[rivet]

When I do a search in the browser which is accessing FMP via WC, FMP stays in the find mode and does not return to browse. Has anyone come accross this?

[Unable]

Yes, that is what is supposed to happen. When the next -action is taken on the db (e.g. you -edit the record you found) that won't necessarily change (in order to edit you must use the record id to find the record to be edited). If the next action is -findall (same as Show All Records) then the db will be left in that condition.

Additionally, just the other day I noticed that finding a set of 100+ records happened in the db as quickly as the click on the browser, but because of the load of ugliness on the returned format file it took a number of seconds for the success.htm to load. This delay had nothing to do with FMPro.

The operation of FileMaker by a client through a browser is "stateless". A new connection is made with the db each time an action tag is submitted from a browser. You'll get to feel very comfortable with this in time.

[Vaughan]

This is odd. Are you using Instant Web Publishing?

With Custom, FMP rapidly flicks between find and browse modes as the find is performed. Web Companion is remote-controlling FMP to perform the tasks. But after each find it must return to browse mode to see the results.

I'm thinking that maybe IWP is returning into Find mode again after returning the results in Browse mode.

[Unable]

"With Custom, FMP rapidly flicks between find and browse modes as the find is performed."

Oops. I see my mistake.

The db file does return to "browse" mode after performing the find of multiple-records. It just retains the found set in browse mode.

[Vaughan]

Good, you have no problem then!

It does highlight the issue, however, that the machine used to web-share the databases should *not* be used by anybody else because Web Companion and the other user will interfere with each other.

[Steve T.]

Hi, Vaughan! If you have time, please explain what you mean--I don't get it.

Are you saying the Web User will interfere with...

(a) a user sitting at the host machine (kinda funny.. web user searches make records jump)

(: another network user (multi-user option)

© another web user

Reciprocally, as far as I've noticed at least, web users are not affected by any other users and (a) is the only one who would notice.

Thanxalot! --ST

[Unable]

If the person sitting at the host machine has a record locked ... ?

[Vaughan]

I refer to the machine that is running Web Companion -- this is the machine that is serving the http requests.

As users perform actions, Web Companion is performing finds on the database. You've noticed it automatically changing modes, entering find requests and finding records. These actions are performed in response to web users. Web Companion queues up the browser requests and processes them serially in the order they arrive. That way different actions don't interfere with each other.

But if somebody was sitting at the same machine trying to do work (often referred to as the "console" to indicate they are local to the server) there are problems. The user might be entering information into a record when suddenly Web Companion will perform some other action and FMP will switch databases, change the current found set or even delete records. If the user at the console opens Scriptmaker or enters the Define Fields dialog (or some other modal process) all other processing is halted until the user has finished -- the web users will think the site is down.

I don't think the console user can cause a record to be locked simply because Web Companion takes over the console while it's processing the web user's request. However if the database is multi-user and another peoson is connected in through FMP as a guest then a record could indeed be locked. Any edit or delete action by the web user will fail, and they will receive an error messsge.