try [url=http://www.mediamonkey.com/forum/viewtopic.php?t=7920]SwitchOrCopyFields: Switches or Copies song data fields[/url]

I'm a scripter, but in MM3 I'm not sure how to change a song's albumartist.

When I loaded my tracks, MM crazily used a right subset of the Artist as the AlbumArtist (e.g., Davis for Miles Davis)

I'd like to use SQL for the fix.

Do I have to separately update the Songs table (to fix AlbumArtist) and the ArtistsAlbums table?

Has anyone already been here?

FYI: I have been using Sqliteman with the MM3 DB.

The 1.0 stable version does not support IUNICODE but the 1.1 2008-02-20 snapshot (latest available) does.

UI is fairly intuitive, no problems noted once I switched to the snapshot.

[url]http://sqliteman.com/[/url]
[url]http://sourceforge.net/project/showfiles.php?group_id=189610[/url]

[quote="RedX"]For what do you want to use the ODBC driver?[/quote]

Not for Access. I'm a dBase/xBase geek. I occasionally like to update my Custom3 field based on a string in the path of the song. I use Custom3 for the file source. So for instance, I have a regular weekly download of songs that go into a directory that might look like this...

"C:\My Music\XYZ Downloads\20070404"

The last portion of the song path is the date of download. I would like to place into my Custom3 field the value of "XYZ-20070404". So I have a dBase script do three things. First, it brings the entire songs table down to a dBase file. Second, it globally replaces that dBase table to update whatever fields I want to be updated. Something like...

Filter:
Path contains "XYZ Downloads" and Custom3 is empty.

Replace: Custom3 with an expression that pieces together "XYZ-"+ the proper date string pulled from the path. Or occasionally I might want to globally change the path to songs. You know, whatever needs to be modified. :)

The third thing in the script is a process that pushes the dBase table back up to the SQL server (oops... Access), matching on SONGS.ID and updating whatever fields I've modified in the dBase file.

It sounds complex but it gets easier after you've done it a few thousand times. :) And it's just the push of a button.

So actually, to really answer your question I should mention that I do the above to any database that I can access through the Borland Database Engine (BDE). But the BDE does not have a native driver for the new MM SQL engine. But the BDE can also go through an ODBC source. I'm concerned that if the new MediaMonkey SQL engine is done purely in-house then they're going to have to provide something to us, or the only access to the MM data will be through the MM interface or MM scripts.

[quote="RedX"]For what do you want to use the ODBC driver?[/quote]

Probably to use it with Access...

For what do you want to use the ODBC driver?

Has anyone gotten anything through an ODBC driver yet? The only one I can find [url]http://www.ch-werner.de/sqliteodbc/[/url] hasn't worked at all for me.

well.. I don't see why it can't be stored in the tag as a semicolon divider...

but if the tag is this:
jack johnson;paul simon

it should be displayed in the tracklist as this:
jack johnson | paul simon


and while it may use semicolons in the tag... it doesn't even need to show them to the user in tag editing.. instead a field can be shown with the ability to click a plus and add other artists rather than typing in the semicolon manually.

Yes, I've been thinking of that myself. It isn't the nicest way to display multiple artists with semicolons in between but I'm not sure how to solve the issue so it's compatible with other applications and ID3 standard.
Helium's way seems to be rather nice though.

Perhaps the dev's needs to re-evaluate this and come up with a nicer solution?

|The Beatles|and|The Rolling Stones|feat.|Aerosmith|,|Derek & the Dominos|&|Queen|

The Beatles and The Rolling Stones feat. Aerosmith, Derek & the Dominos & Queen

[quote="Bex"]
The implementation of multivalues fields works like this:
Lets take artist as an example.
The Artist(s) of a song are stored in the Songs table in the field Artist. If there are multiple artists they are separated with semicolons. (That's how you enter multiple artists to a song.)
[/quote]

Is there any word whether separation with semicolons is going to be the final way of implmenting multiple value fields?

Let's hope not. I know thats the way WMP handles it, but IMHO this solution really looks ugly and you're unable to distinguish between main performers and featured artists.

The devs really should look at Helium Music Manager's approach which seems to be quite neat.
They introduced a new field (and also a custom ID3 tag) "multiple artists" that divides the single artists by putting "|" around them. Between the artists you can put the form of involvement like "feat.", "and", "with" or dividers like "&", "/" and ",".
A string would e.g. look like:
[code]|The Beatles|and|The Rolling Stones|feat.|Aerosmith|,|Derek & the Dominos|&|Queen|[/code]

The usual "artist" the example string would be stored as:
[code]The Beatles and The Rolling Stones feat. Aerosmith, Derek & the Dominos & Queen[/code]

For display of the artists in playlists etc. the "artist" field would be used. But for linking songs to the individual artists the "multiple artists" field comes in play.

fyi, you can be sure that an announcement will come out from Jiri once the schema is finalized.

There are still a couple of schema changes expected in relation to making MM more compatible with Allmusic metadata and possibly in relation to classical music support (depending on the feedback we get).

-Rusty

@Pablo
Yes, I knew you would like the changes regarding putting all fields in Songs table!
If you want any help with the SQL-part in MN, let me know!

@Lowlander
That would be nice.

I also would be nice if the developers can indicate when the database is feature complete. That will allow me to start figuring out how to connect to it from ASP.

Thanks for the report Bex :).

The changes make a lot of sense. I look forward to make MagicNodes compatible with MM 3.0. When all is said and done most queries will likely be easier, and incompatibilities between fields will be gone.

Yeah, you're right Steegy! (Eventhough I'd like to get the stupid ODBC to work...)

Anyway, I figured out the changes now and they seems to be good. All fields that earlier were in AddSongInfoInt and AddSongInfo has been moved to the Songs table which imo is a dramatic improvement. The number of fields in the songs table increased from 45 to 89!

The implementation of multivalues fields works like this:
Lets take artist as an example.
The Artist(s) of a song are stored in the Songs table in the field Artist. If there are multiple artists they are separated with semicolons. (That's how you enter multiple artists to a song.)
The individual artists are as before stored in the table Artists but you don't have the field IDArtists anymore in the Songs table. So you can't link the Artists table to the Songs table any longer. Instead you must link through the new table ArtistsSongs which consists of ID, IDArtists and SongsID.
Like this:
[img]http://img472.imageshack.us/img472/2085/mmartistslx1.png[/img]

If we now query two songs. One with two artists, Abba and Roxette, and one with one artists, Faithless. We actually get three rows of data:
[img]http://img490.imageshack.us/img490/8286/mmartsis2gi9.png[/img]

This leads to that the first song is listed both under Abba and Roxette. But it could lead to other unwanted behavior if you count(*) or sum(*) something. I suspect that the use of count(distinct X) and sum(distinct X) will increase in such SQL's.

Multiple Genres and AlbumArtists works the same way.