Update Record Server Behavior blows error (its part of CS5.5 standard installation!)

[McFrisco]

One wouldn't expect the code supplied by a MAJOR CORPORATION and WEB DEVELOPMENT TECHNOLOGY LEADER to blow an error on one of the server behaviors it supplies as part of its standard install. But then again, there is reality.  The UpdateRecord.js, to be found in your installation on Windows 7 at ..ProgramFiles(x86(/Adobe Dreamweaver CS5.5/configuration/ServerBehaviors/Php_MySQL/UpdateRecord.js  causes an error when it is selected from the SERVER BEHAVIORS menu.  This happens BEFORE you I enter anything into the fields.  The error states:  "While executing onLoad in  UpdateRecord.htm, the following JavaScript error(s) occured: At line 687 of file "........UpdateRecord.js":  name has no properties.  I've looked at the code and it is beyond my comprehension.  Something about the NAME of a value in the node list.... I just don't have the chops to go rewriting Adobe's code.  If I did, I'd be making the big bucks.  Does anybody know what to do about this? About my system:  Windows 7, 64bit,   CS5.5 (on a lease so it is up to date) using PHP and MySQL, on a remote dedicated server running Apache on Linux.   :<)McFrisco

[Ben M]

Javascript errors are very common in the programming of Dreamweaver.  And please don't say that you never have any problems from any major corporations.  That's just plain ignorant.  Microsoft has errors occur in their software, Apple does as well, even outside technology, Toyota has had recalls, Ford has had recalls, airlines have delays, Sony's Playstation network got hacked and went down, etc., etc., etc., etc.

So if you took the time to search for such a common error instead of starting a rant at the first sign of something not working you would have found that Adobe knows the problem can happen in certain instances because I'm guessing the Adobe software wasn't the first thing and only thing you installed on this computer and you can't expect them to test for every piece of possible software that can be installed.  The answer is in the following KB article:

http://kb2.adobe.com/cps/405/kb405604.html

[McFrisco · Accepted solution]

Ok, I deserved that spanking.  I was just frustrated.  Sorry for the rant. 

I've managed to figure out a workaround on this.  There really is something wacky going on with Dreamweaver and the Update Record handler.  Here's what I did:   

How to trick DREAMWEAVER into writing an UPDATE RECORD. 

Dreamweaver's server behavior for Update Record doesn't work correctly sometimes.  The symptom of this is that when you try to fill in the popup form provided by the Server Behaviors/Update Record menu item, it doesn't allow you to choose form fields to update to the database if they are posted there by a previous page.  It only allows you to choose them if they are bound to the database.  This doesn't do any good, because you are updating a record with the information from the database you want to update, NOT with new information.  Kind of weird... But here's the way to get around it.  Its a bit tedious but it works.   

1.  On a clean php page, set up a form with the input fields matching the database fields you want to update.  This page is to be used as the RESULT page of a form submitted on a previous page where the UPdate Record won't work due to conflicts, plugins, or some other unknown reason.   

2.  Connect to the database table you want to update,  and set up a new RECORDSET on the page. 

3.  Bind all the form fields to the appropriate database fields. 

4.  Do an Update Record behavior based on this form.  This will actually do nothing but update the record with the stuff that is already in the record, as noted above.   

5. Delete the php code that sets up the record set.  But, LEAVE THE Update Record code alone!  It is correct.   

6.  Change the bindings of all the fields in the FORM to the $_POST[] variables passed from the form on the previous page. (Make sure the previous page form uses the POST, not the GET method.)

Now, when you submit the form it will pick up the values in the form, which have been passed from the previous page's form.