Nice idea. Trouble is the note table is used to hold notes for many different reasons, so it looks like this - ----------- ------------ -------- | Artist | | Recording | | Label | etc. ----------- ------------ -------- | artist_id | |recording_id| |label_id| | note_id | |note_id | |note_id | ----------- ------------ -------- | | | | | --------------------------------------------------------- | ---------- | Note | ---------- | note_id | | notes | ---------- It looks as if there wasn't anything I was missing - I'm just going to have to break the code up into separate SQL Methods. The example I gave was quite simple compared to some of the updates I have to deal with. Thanks anyway. At 17:40 16/10/00, you wrote:
Or you could renormalize your data to have:
--------- ----------- | Artist | | Note | |---------|-------|-----------| | id | | id | --------- | artist_id | | note_str | -----------
you now have a list of notes by artist_id. You typically won't have a screen that doesn't have an Artist context to be adding a note to. (or to remove all notes from). Of course this means more work to migrate :-( And I don't know all possible scenarios for which you would need the structure you gave, but it is another way around this. It probably doesn't solve real complex scenarios either.
JAT
Dale
Richard Moon richard@dcs.co.uk