VERY unexpected result with a submit form.

[ibiubu]

I was working on a cdml layout that included a pretty standard form. An example:

<form action="FMPro" method="post">

<input type="hidden" name="-DB" value="@task.fp5">

<input type="hidden" name="-Format" value="main.htm">

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

<input type="text" size=12 name="Country" value="[FMP-field:Country]">

<input type="text" size=12 name="Contacts 3::State" value="[FMP-field:Contacts 3::State]

<input type="submit" name="-Edit" value="Edit This Record">

Now when the page is viewed the two fields are populated from the FileMaker database. One field is from the main database, one field is in the same layout in the main database but is a related field. You can of course edit the text, hit the submit button and the record is updated.

The odd behavior is that the main database is updated, but for every time I hit the submit button, a new record is created in the related database.

I dont get it. I have read thru different posts and thru the CDML literature, but still dont understand why this is happening. Any suggestions would be appreciated.

Larry

[Keith M. Davie]

In Define Relationships have you allowed the creation of new records?

[ibiubu]

I checked and double checked for that...The settings for create records is turned off.

LR

[The Bridge]

Perhaps using

<input type="text" size=12 name="Contacts 3::State" value="[FMP-field:Contacts 3::State.1]">

will force FileMaker to enter the data into the first related record, if you're using v5+.

[ibiubu]

Again, one of those odd things in filemaker that should not be happening. Anyway, the above suggestion worked, but I had to invert it as such:

<input type="text" size=12 name="Contacts 3::State.1" value="[FMP-field:Contacts 3::State]">

Thanks for the help.

LR

[Keith M. Davie]

FWIW

TechInfo Article: 107206

http://www.filemaker.com/ti/107206.html

[The Bridge]

My mistake -- glad you got it worked out!

[ibiubu]

OK, so here is a wrinkle to all this.

<form action="FMPro" method="post">

<input type="hidden" name="-DB" value="@task.fp5">

<input type="hidden" name="-Format" value="main.htm">

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

TABLE ITEMS

<input type="submit" name="-Edit" value="Edit This Record">

Where TABLE ITEMS is a table representing a portal. I am of course using the proper [FMP-Portal:Contacts 3][/FMP-Portal]

My table then holds items such as

<input type="text" size=12 name="Contacts 3::State.1" value="[FMP-field:Contacts 3::State]

Here is the problem. If I have multiple items showing in my portal in my database, they of course also show up on my web page in my table. I can make edit changes to line one in the table, hit submit, and the change is submitted to the database. But if I try to edit anything from line 2 and on, hitting the submit button does not submit these changes to the database.

My guess is it has something to do with the .1 added in the cdml tag. How can i possibly get past this so that I can edit each line of the portal via each line in my table on my web page?

LR

[Keith M. Davie]

Larry, I referred you to a techinfo article which discusses this and presents an example which uses:

Phone::PhoneNumber.0

Your code shows:

Contacts 3::State.1

Why would you not think to use:

Contacts 3::State.2 ?

(Though for web use I would have used "contacts3" or "contacts_3")

[ibiubu]

Read the article.

Tried many variations including:

Contacts 3::State.0

Contacts 3::State.1

Contacts 3::State.2

Contacts 3::State.1 just allowed the editing of row one of the table. This would be row one of the portal in the database.

Contacts 3::State.0 and Contacts 3::State.3 actually did not edit the record, but instead created an entire now portal record with the new information, leaving the original portal record untouched.

LR

[slstrother]

I had the same problem. Adding a .0 or a .1 after the field name did not help. I ended up making an edit.htm page linked directly to the related file, where the user can edit the items then return to the main page.

[Anatoli]

I am not fully in picture here, but the syntax is: Relation::Fieldname.[FMP-CurrentPortalRowNumber]

[ibiubu]

Anatoli,

Thank you. That one clarified it. I am assuming by manually adding something like .1 to the cdml it is hardcoding it to portal row 1. So even if in my table on the web page if I make changes to row 5, it is trying to submit the changes to row 1. By adding .[FMP-CurrentPortalRowNumber] to the solution, now each row in my table has the correct corresponding .# assigned to it.

It makes good sense how this works now. Thanks again for the insight.

Larry

[Keith M. Davie]

Ok Larry, I didn't get that you had tried it. Glad you did. Sorry it didn't work. But then, Anatoli came through again. Good call Anatoli.

[Garry Claridge]

The ".0" actually represents a new row. Unfortunately, this is a little illogical because we usually associate a new row appearing at the bottom of the portal. However, it is easy to use if you do wish to create a new row.

All the best.

Garry