How to remove URL data?

The way that DW currently builds the URL data to pass IDs to detail pages,
if we process an UPDATE to a database, when we go to the referred page after
the update, the ID remains in the URL, so any attempt to update another
record winds up with two different ID=xxx statements in the URL, which of
course, doesn't work! How do I go about modifying the DW code so that after
the Update, the ID is removed from the URL?

The workaround for me has been to refer to a blank static page with meta
refresh pointing back to the detail page... ugh! Not pretty... Suggestions?
Can this be turned off?

_Adrian wrote:

The way that DW currently builds the URL data to pass IDs to detail
pages, if we process an UPDATE to a database, when we go to the
referred page after the update, the ID remains in the URL, so any
attempt to update another record winds up with two different ID=xxx
statements in the URL, which of course, doesn't work! How do I go
about modifying the DW code so that after the Update, the ID is
removed from the URL?

The workaround for me has been to refer to a blank static page with
meta refresh pointing back to the detail page... ugh! Not pretty...
Suggestions? Can this be turned off?

Easiest thing is to send it to a blank page (as you're doing), but use
server side code to redirect to the proper page.

--
kindler chase
http://www.ncubed.com
Home of SuperInvoice: The Online Invoicing Application.
Organize your billing process and impress your clients.

news://news.ncubed.com/support
n3 Support Group

Thanks Kindler.. I could have sworn that someone somewhere had explained
once how to remove specific chunks relative to the KeepURL commands...
[sigh]

The Macromedia Update script includes some code to pass any details in the URL,
you can delete this code from the page with no harm to the update behaviour.

Look for the below code, and remove it.

' append the query string to the redirect URL
If (MM_editRedirectUrl <> "" And Request.QueryString <> "") Then
If (InStr(1, MM_editRedirectUrl, "?", vbTextCompare) = 0 And
Request.QueryString <> "") Then
MM_editRedirectUrl = MM_editRedirectUrl & "?" & Request.QueryString
Else
MM_editRedirectUrl = MM_editRedirectUrl & "&" & Request.QueryString
End If
End If

I have found it useful to remove this code when I have wanted to pass my own
URL data, which has the same title, and as you found, ends up with duplicate
values, and thus your pages do not work 100%.


Originally posted by: Newsgroup User
The way that DW currently builds the URL data to pass IDs to detail pages,
if we process an UPDATE to a database, when we go to the referred page after
the update, the ID remains in the URL, so any attempt to update another
record winds up with two different ID=xxx statements in the URL, which of
course, doesn't work! How do I go about modifying the DW code so that after
the Update, the ID is removed from the URL?

The workaround for me has been to refer to a blank static page with meta
refresh pointing back to the detail page... ugh! Not pretty... Suggestions?
Can this be turned off?

If you are using the Go to Details page behaviour, then there is a tick box to
say whether it passes the current URL or not, unticking this will stop any
details in the URL being passed.

I would recommand moving from the Go to Details behaviour anyway, as it uses
too much code to do something very simple, which you can build by hand using
your recordset, you simply type the url as normal

page.asp?UniqueID=<%=recordsetname("columname")%>

thus you have a quick and simple way to pass variables in the URL, without the
tons of code Dreamweaver uses, and you also remove the passing of additional
URL details.


Originally posted by: Newsgroup User
Thanks Kindler.. I could have sworn that someone somewhere had explained
once how to remove specific chunks relative to the KeepURL commands...
[sigh]

_Adrian wrote:

Thanks Kindler.. I could have sworn that someone somewhere had
explained once how to remove specific chunks relative to the KeepURL
commands... [sigh]

I usually do not recommend fiddling with the stock MM code; mostly because
if you ever have to use the native MM Server Behaviors to update your page,
you may lose your hand edits. The server side redirect is fairly quick and
simple to set up as well

--
kindler chase
http://www.ncubed.com
Home of SuperInvoice's Groove Thang

news://news.ncubed.com/support
n3 Support Group