Thanks for your suggestion!! Sounds like a good route to go down with the API access. Really struggling with the pending 'list' at the moment. Suppose I have got 2 tables `product` and `description`. `product` contains `EAN`, `name`, `last_modified` and `description` contains `EAN` and `description`. The nearest thing to me right now is a tub of pencils.
EAN: 5011772007888 Name: 50 Staedtler HB Pencils Description: A tub of 50 HB Pencils by Staedtler. Suppose someone at BarcodeDB.com, having signed in, wanted to change the description to: A tub of 50 HB Pencils by Staedtler. With strong break resistant leads, they make an ideal pencil for kids or adults alike. Rather than update this description straight into the database. It would be nice for it to wait to be approved, and once approved a 'history' is kept so it is known who submitted the data and who approved it. Any ideas on how to achieve this effectively?? -- How about you add two extra fields in your 'description' table - 'UniqueID' and 'Approved.' Each time a new description is added or updated, it creates a new field in the description table. UniqueID auto-increments. 'Approved' is set to 0 until it has been approved (set to 1) or rejected (-1). This will make it easy to list pending approvals, too. The code can default to show the most recent (based on 'UniqueID') approved description. This has the advantage of having a full history of descriptions, and whether they were approved. You could expand it by having further fields (SubmittedID, ApproverID) to track that. And you could choose to have the 'Product' table hold the UniqueID of the currently chosen description, if you want the flexibility to choose a description that isn't the most recently submitted one. Jon.
