You can't just dump your files into the web folder as I understand it. You'll also need to update the file references to point to this folder in place of their original folder. You can use replace field contents and treat the container fields just like they are text fields in order to do a batch update of the existing records so that their container fields point to the web folder. You may want to place a calculation field on your layout temporarily to see the format of your inserted "by reference" fileds. The format will differ depending on whether, insert file or insert picture was used.
You can put the name of the container field as the sole term of the calculation and specify text as it's return type. You can then place this field next to your container field to see the format of it's file references in order to determine how to update them.
IWP users will not be able to insert new files into container fields unless you use something like the third party produced tool called SuperContainer. This is a know limitation of IWP.
Note: Replace Field Contents is not something you can Undo. Make a back up copy before you try it out so that you can toss your current file and try again if it doesn't produce the results you expected.
Oh yes, and you aren't missing anything about how to post follow up questions.
Post A Answer is both tragically bad grammar and also mislabeled. I'd rather see it named "post a reply" or some such, but am told the current link name is "hard wired" and can only be changed by the rightNow programmers...
As always your answers are very helpful. I was wondering, when it comes time to do some changes to the database I have hosted on the server, what is the best way in which to pull down the most recent copy from the server, make changes, and then put it back up? It is hard to find this information in the server literature.
It depends on your users. If you can access the server "after hours" when no one else is using the database, you can close the file and then drag a copy of it across the network to your computer, you make the changes and then repeat the process in reverse.
You can also design your database according to the data separation model. This puts all layouts, scripts, value lists in one file and all data in a second file. Since many if not most updates change a layout, or other part of the interface rather than the design of a table, many updates can now be uploaded to your server just by swapping out the old interface file for the new.
A second approach you can use (and still one to use whenever you have to update the design of the data file), is to update a copy of the file, save an empty copy of the file, then use a script to import all data from your current copy into the updated copy. This script can also update serial number fields to change their next serial value settings to be consistent with the imported data.
And I do sometimes make small changes directly to the file on the server. I have them set up for frequent backups and make such changes with extreme care. I can get away with updates to a layout or script, but do not attempt changes to a table or relationship while the database is in use. Changing a field definition or other aspect of Manage | Database can lock all users out of an entire table while the update is committed when you click OK to dismiss Manage | Fields and if a network glitch disconnected you while in the middle of committing such an update, it could damage the file.