We are well past that. See threads 46, 50,51,The songs are duplicated in the subform because there are multiple artists. two artists = 2 rows. Three artists = 3 rows, etc. Add grouping to the query and that will eliminate the duplication. It also makes the subform not updateable so you will need a separate form to do updates or add tracks. Just use the double click event of the song titls to open the single record form and edit there
Are you sure this is the current version. I think your intent is to be able to assign multiple artists to a track, but in this example the junction tableLook at the difference between the relationship schemes, then you probably can see what I've done to the one you've been working with.
Yes, yes, yes. It's an older version.Are you sure this is the current version. I think your intent is to be able to assign multiple artists to a track, but in this example the junction table
tbl_Music_Artist is missing. That looks older not newer.
No need I have been following the discussion, I know where you are and why. It all makes sense to me. This design makes sense. I will add my demo to V4. The only thing would be if you did modify your naming conventions (especially to keys) seen in thread 11, this would be a lot easier for others to understand. You have some really confusing keys and I think this confused people in your initial posts.I posted it because I wanted you to see what it looked like before I started adding what was suggested in this forum.
My problem in this version was just adding tracks performed by more than one artist.
For simiplicity I will demo with just a standard form and subform. This will be more flexible and require less code. You click on that track and get a pop up with the main form being track information and the subform being assigned artist. Then you can Add and delete artists in the subform. No code needed. The subform probably needs FAYT combos so you can pick from the large list of artists.look forward to the list box that you will add.
The name autocorrect is a powerful feature in Access and can do most of the heavy lifting. You change a field name and it will change in the queries and rowsources/recordsources of form's and controls. I does not change in vba. However, if you write down your changes you can do find and replace throughout the code project. To me it is worth it to spend the time. I try to make my naming convention such that another person could easily figure out what my fields do. I do not do a lot of comments in my code because since my names tend to be long, consistent, readable and descriptive.Is there a simple way to auto change it?
Oh yeah, I was definitely being snotty.I did not perceive MajP as snotty
Yeah, I actually did. Not only did I tell him I actually looked at the database and determined the tables that needed to be removed and called them out by name. I also provided the reason why it was read only, a working demo, and a screen shot showing no duplicates.You never told lodmark what caused the problem.
In the query both the artist table, and artist_music needed to get removed or they would cause duplicates. That information is pulled in through the calculated
I will definitely test this when or if you have finished the work you are doing with the file now.The name autocorrect is a powerful feature in Access and can do most of the heavy lifting. You change a field name and it will change in the queries and rowsources/recordsources of form's and controls. I does not change in vba. However, if you write down your changes you can do find and replace throughout the code project. To me it is worth it to spend the time. I try to make my naming convention such that another person could easily figure out what my fields do. I do not do a lot of comments in my code because since my names tend to be long, consistent, readable and descriptive.
I clean up my table and field names all the time. If I come back to a database and have to guess what I was doing, then I know it was not a logical choice. If you wanted to do it, make a backup (good to do all the time anyways) and give it a try. Without knowing your database I would know what a TrackID, AlbumID, TrackID_FK, AlbumID_FK are. I have to think about what is a record versus music and for sure have to think what a record_record_music and record_music_record are. The other reason for me if in the software systems we use (ITunes, MediaMonkey, etc.) the terminology is commone 'tracks' and 'albums'.
I may have asked this before, but do you use "Media Monkey"? If not familiar this is a freeware media system that blows away ITunes. I cannot even use ITunes because MM does everything that you wish ITunes would do and fixes everything you hate about ITunes. The reason I ask is because you could adapt some of the user interface ideas from there. If I got time I will demo some.
I am not suggesting you need to change your names, but if you do it is not all that hard. But if you do I would wait until I have given you the demos and you have incorporated them. That way the name autocorrect will update a lot of what I have done. I would wait for now, until there is a good stopping point.But I thought it was wrong of me to go in and change the tables while you @MajP were creating things in the database.
I was afraid that I would then change something that would make the solution you presented not to work.
No. I am building a MM like view in Access. As I said, it gave me inspiration for a user interface.You've imported my database into Media Monkey.
OK, I understand.No. I am building a MM like view in Access. As I said, it gave me inspiration for a user interface.