Won't Post Data

[Chirriras]

New day, new problem.

I have a questionnaire page, it has check boxes, radio buttons and text boxes. I've double checked to be sure that the values on both the CDML page and the database match. At the top of the web page I have:

[color:"red"]

<FORM ACTION="FMPro" METHOD="POST">

<INPUT TYPE="hidden" NAME="-db" VALUE="HRWL.fp5">

<INPUT TYPE="hidden" NAME="-format" VALUE="WLSurvey2.htm">

At the bottom of the page is:

[color:"red"]

<INPUT type="submit" name="-edit" value=" Submit ">

<input type="hidden" name="-recid" value="[FMP-CurrentRecID]">

I'm currently testing it on localhost. When it opens WLSurvey1.htm, it creates a new record in the database, but when I fill in some questions and click the submit button, nothing happens.

The database name and next page are both correct. What have I left out?

[Garry Claridge]

Is the [FMP-CurrentRecID] rendering in the browser OK?

Garry

[danabase]

Are you sure you have all the basics? I believe you need to specify a layout name, and I always specify the RECID at the top; only button info, tokens or inlines elsewhere:

<FORM ACTION="FMPro" METHOD="post">

<INPUT TYPE="hidden" NAME="-DB" VALUE="HRWL.fp5">

<INPUT TYPE="hidden" NAME="-Lay" VALUE="whatsurlayoutname">

<INPUT TYPE="hidden" NAME="-RecID" VALUE="[FMP-CurrentRecID]">

<INPUT TYPE="hidden" NAME="-Format" VALUE="WLSurvey2.htm">

Later...

<INPUT NAME="-Edit" TYPE="submit" VALUE="Submit ">

</FORM>

[kfutter]

No, you don't need to specify a layout name, except where field availability or access privileges are tied to a specific layout. If you don't specify one, Web Companion assumes you want to talk to and retrieve info from the entire database.

Having said that, I can't see why the original poster's code isn't working.

Cheers,

Kevin Futter

[Unable]

re: If you don't specify one, Web Companion assumes you want to talk to and retrieve info from the entire database.

NOT

I understand FMP defaults to the first layout. Further, fields must be on the layout for FMP to read them. It has often been advised on these forums that for web development is best to have one layout dedicated to the web (often called either web or cgi) which has all the fields on it which the web soluiton must access. The nice thing about that layout is it does not require an fancy design, only the fields and those in no particular order. The only exception which allowed a field to be omitted from a layout is if the field is an unstored calculation, but that functionality may have ended with version 5.

[Garry Claridge]

The only time, I've found, that the "-lay" tag is needed is when you are using Portals. Even with a Blank first Layout.

It is good practice to avoid using Layouts with lots of calculations etc on them as they may slow WebCompanion performance. Hence, purpose built Layout are good for web use.

All the best.

Garry

[kfutter]

I rarely specify layouts in my query strings and *many* times have I retrieved data from fields not present in the first, or any other, layout. *My* understanding is that FM employs a default internal layout that contains all fields - a meta layout if you will - and this is what is used if no specific layout is called.

But I do agree with the notion that it is better to establish 'web' layouts where possible or practicable.

Cheers,

Kevin Futter

[Unable]

My understanding was based on "FileMaker Pro 4 and the Worldwide Web" (Feiler), p223:

"-Lay Layout name. The name of the FileMaker Pro layout to be used; it primary purpose is to describe the fields that are to be used in this request. If omitted the first layout for the database is used - this is almost always inefficient."

[kfutter]

I see. All I can assume is that this behaviour has been changed since v4 - we're using FMU6 & v5.5 Server. In at least one case, I check the value of field that doesn't exist on any layout, without any problems. Unless of course the book's description of 'first layout' is semantically synonymous with my concept of the internal layout holding all fields.

The comment about not specifying layouts being inefficient is probably still true though. The reason I rarely specify them is because I don't necessarily have sufficient opportunity to create web-specific layouts for our 90+ databases (very few of which have been created by me). It is on my 'to-do' list however!

Cheers,

Kevin Futter