The problem is there's no way to access an arbitrary node.
Well actually, there is. Look at the BrowseToNode function in the StartupNode and FavouriteNodes scripts.
This function tries to go to the specified node and then uses the reference of the found node to set it as current node.
You could change it just a little bit by replacing
by
Code: Select all
If Err <> 0 Then
CreateTheNodeStructure
Exit Function
so that instead of just leaving the function returning false (when a node in the node structure specification doesn't exist), it would start another method to create that node, and the specified subnodes.
When the function finishes, the node reference would always be available (by browsing to it or by adding it), so from then on you could use Magic Nodes to use that node reference as parent for the custom node structure.
Example:
:: "parent" specification in custom node1 = "Library>Genre Groups>Rock"
:: "parent" specification in custom node2 = "Library>Genre Groups>Pop"
For the first node, the BrowseToNode would run to the "Library" node, and because it doesn't find the subnode Genre Groups, it will add the rest of the structure: "Genre Groups>Rock".
For the second node (so "Library>Genre Groups" already exists), the BrowseToNode would run to the "Library>Genre Groups" node, and because it doesn't find the subnode "Pop", it will add the rest of the structure: "Pop".
A special specification like "parent:%genre%>Genre Groups>Rock" would enable the script to begin searching from the built-in Genre node (with available reference). The only reasonable purpose of this would be that the nodes then still work correctly even if the MM language is changed.
So you could use "parent:%artist%>NewNode" for all languages, instead of "parent:Library>Artist>NewNode" in English and "parent:Library>Artiest>NewNode" in Dutch.
This behaviour would be a combination of FavouriteNodes/StartupNode version 1, and the current versions.
If you are interested in adding this, I always want to code that piece. (It's looks not so difficult anyway
)
+++++++++++++++
So I believe Access has some built-in protection against redundant code while JET doesn't.
Or, it's because the Jet Engine throws an error that MediaMonkey doesn't handle correcly and so goes 100%.
I tried the problematic SQL query in MsAccess and it works (very fast).
I tried it using manual DB connectivity (using ADODB.Connection object), and the Jet Engine returns an error...
So it's probably an error in MediaMonkey, and not in the specifically the Jet Engine (which doesn't execute correctly, but does give a correct error).
Cheers
Steegy
[quote]The problem is there's no way to access an arbitrary node.[/quote]Well actually, there is. Look at the BrowseToNode function in the StartupNode and FavouriteNodes scripts.
This function tries to go to the specified node and then uses the reference of the found node to set it as current node.
You could change it just a little bit by replacing[code]If Err <> 0 Then Exit Function[/code]by[code]If Err <> 0 Then
CreateTheNodeStructure
Exit Function[/code]so that instead of just leaving the function returning false (when a node in the node structure specification doesn't exist), it would start another method to create that node, and the specified subnodes.
When the function finishes, the node reference would always be available (by browsing to it or by adding it), so from then on you could use Magic Nodes to use that node reference as parent for the custom node structure.
[u]Example:[/u]
:: "parent" specification in custom node1 = "Library>Genre Groups>Rock"
:: "parent" specification in custom node2 = "Library>Genre Groups>Pop"
For the first node, the BrowseToNode would run to the "Library" node, and because it doesn't find the subnode Genre Groups, it will add the rest of the structure: "Genre Groups>Rock".
For the second node (so "Library>Genre Groups" already exists), the BrowseToNode would run to the "Library>Genre Groups" node, and because it doesn't find the subnode "Pop", it will add the rest of the structure: "Pop".
A special specification like "parent:%genre%>Genre Groups>Rock" would enable the script to begin searching from the built-in Genre node (with available reference). The only reasonable purpose of this would be that the nodes then still work correctly even if the MM language is changed.
So you could use "parent:%artist%>NewNode" for all languages, instead of "parent:Library>Artist>NewNode" in English and "parent:Library>Artiest>NewNode" in Dutch.
This behaviour would be a combination of FavouriteNodes/StartupNode version 1, and the current versions.
If you are interested in adding this, I always want to code that piece. (It's looks not so difficult anyway :) )
+++++++++++++++
[quote]So I believe Access has some built-in protection against redundant code while JET doesn't.[/quote]Or, it's because the Jet Engine throws an error that MediaMonkey doesn't handle correcly and so goes 100%.
I tried the problematic SQL query in MsAccess and it works (very fast).
I tried it using manual DB connectivity (using ADODB.Connection object), and the Jet Engine returns an error...
So it's probably an error in MediaMonkey, and not in the specifically the Jet Engine (which doesn't execute correctly, but does give a correct error).
Cheers
Steegy