Just an observation...using instant web publishing causes some strange behavior when it comes to editing portals. The scroll bars for the Portals work sometimes, then all of a sudden they will just disappear. Of course Show Scroll Bars is still checked in the options.

Strange behavior to look out for if you use Instant for anything.

LR

One more observation about portal use and Instant Web Publishing...

If ou try to add to a portal through Instant Web Publishing you can only enter items in one line at a time. You do not have access to the next blank line in the portal. You have to hit the submit button, then you are presented with a blank next line. Once you enter info into that one you cant continue to the next line without again hitting the submit button...and so on and so on.

How annoying of a feature is that!

LR

RE: you cant continue to the next line without again hitting the submit button...and so on and so on.

How annoying of a feature is that!

*******************************************************

I just wonder how you will implement that in HTML? What you see is the browser and HTML and NOT FileMaker at all.

You are completely of web logic

Here is a odd solution i just came up with regarding this problem.

The problem with portals is when accessing my database from Web Companion. When creating a new record in my main database, it only allows editing of the first line in the portal that is related to the second database. If you want to add more lines (essentially the same as creating new records in the related database) you have to hit the submit button, wait for the browser to refresh, hit the edit button, then you are presented with a second line in the portal to edit. If you want a third, you have to do the same process again. This can TAKE FOREVER if you have a lot if items to enter into a portal via the web.

The solution I found was a plugin called oAzium Events. To break it down to the basics, I have attached a script to the main database that does the following: If thru the web a new record is created, the script goes to the related database and creates 12 new records based on the related field between the two databases. Now right from the git go there are 12 blank lines in the portal for entering data from the web. For this example I chose 12...but it can be any number.

I know I know...everyone talks about the pitfalls of using scripts when publishing on the web. But for this particular problem this is really the only solution I found that works. (I did not want to create a link that allowed people to go directly to the related database to enter data, I wanted to keep all the data entry in the main database withing the portal)

LR

If you were using Custom Web Publishing you could also use some Javascript (and even some DHTML) and produce a nice solution.

All the best.

Garry

"...this is really the only solution I found that works."

ibiubu, I believe that what you meant to write is "this is really the only solution I found that APPEARS TO WORK.." The reason I suggest this is in all likelihood you have not done rigorous testing of the script in a multi-user environment such that more than one request is made on your script in a near-simultaneous manner. As a developer it is your responsibility to do rigorous testing of your solution. Once the rigorous testing is successful then you can aver that it works.

Again...very aware of the pitfalls of Scripts and the Web. Warning signs posted on a DAILY basis. As much as I would LOVE to avoid them all together...

Anyone offer up a better solution for the portal problem and the web...a solution whose workaround isn't worse than just using a script and 20 times more labor and time intensive (time is money)...I am willing to listen.

Weighing the options, and the fact that I only have 3 people that occasionaly access the database remotely thru the web for administrative purposes...I figure the gains in this instance FAR outweigh the risk.

LR