Using Digital File Pro on multi update page

I set up a series of insert/update/delete etc pages using DA, but have a problem with how this is working. The client needs to be able to add up to 20 items, so I've set up the pages with 20 file upload behaviors, which all work, but every time an item is updated, it deletes whatever else was in that row in the db table... I'd like to know if there's a way round that, for starters. Ideally what I'd like is for the client to be able to see what's in each field, then have the option to leave in place whatever he wants.
The other problem I have is that I need to have all these 20 items added into the same row in the database table - if you upload 4 items and then add 5 more later, the second lot are added to a new row - is there any way to force the uploads to go into only one row?
I've attached the 6 pages that insert/update etc.

On your update page you need to bind the form fields to the values from the recordset to maintain the existing values. When it comes to the images you will need to set the default image in each of your upload server behaviors to the value in your recordset that holds the existing file name.

As for inserting and updating records if you add 4 values initially you will need to update that existing record and not insert a new one. The update page should only ever update records, if there is no insert on this page then it will not insert new records. I only saw the update server behavior on your update page.

Eric - thanks for responding. So - if I understand you correctly, having created my file fields and DFPro upload behaviors on the update page, do I then need to select those file fields and bind them from the recordset? I've attached the update page again with the first item from the recordset bound to the file field - if I've got this right please let me know and I'll do the same for the rest.

I'm still confused about how to be sure that my insert page is not going to generate a new row in the db table - if I know that I've added 4 items on day one and then gone back on day two to add some more, even if I start by inserting something in file field 5, won't it create a new row?

A limitation of using file fields on a form is that you cannot pre-populate them. This is a security thing. So instead of pre-populating the file fields you will just have them like normal so that the user can use them to select a file. You need to have the DFP upload server behavior configured like normal to use the file field, but for the default value you should make sure that you are referencing the previous file name from the recordset and the path is going to the folder where this file is. Since the update server behavior works with the DFP value it will use the uploaded file if one is uploaded and if not it will use the default file specified in the server behavior.

To make this more clear to the user you can add the file name binding to the form above the file fields so that the user knows that a value exists already.

As for the insert page any time you access this page and fill in the form you will insert a new record. Once a record has been inserted it can only be updated through the update page. The insert page will never update a record, it only adds new ones.

Hi Eric, right thanks, I think I have a clearer grasp on this now. So... the first time that the client wants to upload something to this marketreview area, he needs to use the insert page, and for any succeeding additions he needs to use the update page, otherwise it's going to add a new row. Thanks for clarifying that, it makes perfect sense now. The only problem I can see is that if the client uses the update form, he's going to need to upload the files that he's already uploaded (if you see what I mean) otherwise they're going to disappear once the "Update" button is pressed.

I can see your concern, but this should not be an issue. So long as you are setting the default file in DFP to the value that is recorded in the recordset it will use the existing file unless a new one is uploaded. So there is no need to worry about re-uploading the existing files, once a file has been added to the record it should not need to be added again.

I've now got this set up with the default files set to the value shown in the recordset, so this now working exactly as I want - thanks for your assistance.
I now have a slightly different issue that needs resolving. The way things are set up, because this is a single row in a db table, when you want to delete one of the records, the only option is to delete all of them, and the client wants to be able to them individually.
One way round this would be to change the db table so that it contains 20 rows instead of one, but if there's a work-round that I can implement by tweaking the code a bit, I'd be interested to know about it.
Attached zip contains the update and delete pages.

When you are talking about delete within SQL you can only delete rows from a table. If you do not want to delete the whole row but just some info in it you would use an update. You would want to update the row to be just like it is, but make the blank for the values you would like to remove. So it is really the same as an update, you are just updating it to be blank instead. You could set it up just like an update page, you just need a way to select which info to blank out.

I personally think it would be much cleaner and easier to work with if you had each piece of information in a different record in the table. This would make it much easier to manage specific info because you would not have to touch any of the other related info.

I take your point but if I rework the database as you suggest, wouldn't I have to have 20 tables (1 for each record) where I've currently got 1 with 21 rows (id + reviews 1-20)?
Am I being dumb here or wouldn't I then have to have 20 separate update pages, 1 for each table, or is there a way of combining them all into one page for update purposes?

I'm a little confused by your last post, I don't think that I understand the structure of your information.

When I made my last response I suggested just updating a record and blanking out values that you would like to be deleted. This was based on your statement that the info is contained all within a single row in the db:


The way things are set up, because this is a single row in a db table, when you want to delete one of the records, the only option is to delete all of them


I was just making the point that if you do not have the information in individual records in your table you will need to update the record rather than delete it. Currently do you have all of the information contained in a single record or row in your db table? If so you should be able to use this same table and just break the information out into multiple records in the table. I might be misunderstanding the structure of your data, it is possible that there is a more appropriate way to organize your data for the task at hand. If you can describe the data a little and how the data relates to the other data in your db I might be able to help you come up with a structure that is easier to manage.