Could really use some help...

[ChristianLeC]

I have been working on my first CDML database and it has been no small undertaking. I love what FMP can do.

However I have run into a problem with my Custom Web Solution.

I have created my EDIT,Delete, and NEW templates which seem to be working fine when entering new products. The problem arises when I try to edit/delete preexisting products, I get this error message

Unexpected Error

An unexpected error occurred: Couldn't find database name in POST arguments. Click the Back button on your browser to return to the previous page

I just do not understand. The same templates are used to edit/delete new products are are used to edit the pre-existing prodcuts in the database. What could be the difference?

Is there anyone who can help me with this problem?

[Vaughan]

Use the "View source" option in your browser to see what actual html is being generated. The form that does the action should have all the required tags -- db, lay, format, etc.

The most common problem that people have is not specifying the RedID -- a unique identifier to the record in the database that FMP is to edit or delete. It's created using the [FMP-RecID] CDML tag, and carried across multiple pages with the [FMP-CurrentRecID] CDML tag.

[ChristianLeC]

I checked the hidden fields, and it does seem tobe passing on the RedID correctly. For example..

<input type="hidden" name="-RecID" value="2">

<input type="hidden" name="-lay" value="MAIN">

<input type="hidden" name="-format" value="barton/db/edit_reply.htm">

<input type="hidden" name="-db" value="LIQ.FP5">

I retyped in the hidden info, just in case it was not taking for some reason. But it seems to be there, and passing along correctly.

I will take any and all suggestions here. Is there a reason I would be able to Create a new record, edit a new record and delete a new record, but be unable to do any of that to a currently existsing record (a record in the database that was placed in there from teh desktop, not from the web browser editing interface) ?

[ChristianLeC]

Further Information,

I have done some more troubleshooting on this, trying to track down where the problem might be.

Since there are 114 fields to edit, I started removing fields until the form worked again, thinking that maybe it was one of the fields that it was having problems with. Once I got down to 39 fields, the form started working again. So I started adding the fields back in from #39, one by one. No matter what field after that I added back into the form after field #39 the form would come up with the previous error. (Even if I removed some fields and added back in others, the same problem)

Unexpected Error

An unexpected error occurred: Couldn't find database name in POST arguments. Click the Back button on your browser to return to the

previous page

So, I started meticulously checking to make sure the fields were all named correctly (as I said before, this template was the same one working for adding new records, and editing them) but they all are showing up OK.

So, this leaves me once again, confuzzled. There is not a limit on the number of fields you can edit in the database at one time is there?

[Vaughan]

Anatoli -- didn't you identify this limitation in Web Companion a few months ago? Or was it somebody else...

I seem to remember another post about forms with lots of fields being troublesome. As I type thisd it occurs to me that it's probably not a bug in WC but a URL string length limitation -- there has to be some max length, perhaps somebody else will know.

It's been said in these forums several times that a database with hundreds of fields might have a poor data model design.

[yafreax]

POSSIBLE SOLUTION: I think this makes a lot of sense (woah, i might say something entellijent). Try to section off your forms as best as possible into types or "catagories." Knock it down to about 35 -38 fields each and then just have it a multi-page form. This first page creates the records, then everything after modifies that record. Just make sure to pass the RecID tag.

Vaughan, i seem to remember the post as well, but it wasn't very conclusive, Some have had forms with many fields work, while others have had problems. I've had both. Also, i've seen many online forms that reach into the 100's on one page. Granted they may be using a certain program / cgi / whatever specific to large forms, but that concludes that it can be done so FM should probably look into that. Oh, and I wonder if you're gonna get another huge debate stirred up about the size of a database. . . i almost said something, but, nah, i'll leave it alone .

jeremy

[Anatoli]

quote:

---

Originally posted by Vaughan:

Anatoli -- didn't you identify this limitation in Web Companion a few months ago? Or was it somebody else...

---

I think it was somebody else. But to fill such a form - I bet people will be put off.

As far as I am in the picture, the POST is sending data within the header communications. It should work.

[Vaughan]

Anatoli and Yafreax... thanks for the follow-up. You guys (and LiveOak, the Captn and others) are great.

If you're ever in Sydney, look me up.

[Anatoli]

quote:

---

Originally posted by Vaughan:

Anatoli and Yafreax... thanks for the follow-up. You guys (and LiveOak, the Captn and others) are great.

If you're ever in Sydney, look me up.

---

OK just have plenty of Black Swan and Paul Hogan Show tapes :-)

[Vaughan]

I guess I'll be able to get the Black Swan (never drunk it myself) but Paul Hogan *show* tapes? Did they get overseas? Crikey, they were on TV when I was early teenager.

[Anatoli]

I've improved my knowledge about Australia while I stayed in London for 11 years :-)

You guys have similar humor as Czechs.

[abkaplan]

<input type="hidden" name="-db" value="LIQ.FP5">

here you use LIQ.FP5 but you must not use .FP5 with your database name.

try it .

it helped me for the same error mesage.