Manipulation of RigManager Data Programmatically (BE VERY CAUTIOUS!!)

  • Hello GString,

    you wrote:

    we had this before. it resulted in tears and broken data. is it so difficult to accept that it is not a good idea to edit a database without knowing how it works?

    This was the reason why I had warned in my first post. It's fine that there is redundancy in the database; you can design your private tables in a way that is most efficient for your application.

    Nevertheless you seem to miss the point: the interest in database access by several people in the forum comes from the fact that some automated change of tags would be very helpful.

    Note that I am no kiddie trying to test its relational database abilities. I have more than twenty years of experience as an IT consultant and also did several data quality/data cleansing projects on databases orders of magnitude larger than even the Rig table of the rig exchange.

    My problem is that the tagging of the rigs is really inconsistent (although I can understand what legal boundary conditions lead to it). But I do neither want mangled or phantasy names on my Kemper nor being forced to do a manual change. Data cleansing is a job to be automated.

    Hence I have posted a feature request for a small API for the RigManager.

    Best regards,

    DrTT

  • I think when you edit tags in RM the Rm update it in kipr files as well. But when you open it as database you only edit text fields not the Sysex in kipr files.
    It is always better way to edit tags on RM (or editor connected with KPA and then make a save in KPA to store it in kipr file).
    This way you use internal algorithms to store the tags and in that way it is working as it should.

  • we had this before. it resulted in tears and broken data. is it so difficult to accept that it is not a good idea to edit a database without knowing how it works?
    gs

    I think when you edit tags in RM the Rm update it in kipr files as well. But when you open it as database you only edit text fields not the Sysex in kipr files.
    It is always better way to edit tags on RM (or editor connected with KPA and then make a save in KPA to store it in kipr file).
    This way you use internal algorithms to store the tags and in that way it is working as it should.

    Whateven sysex is it's not updated by update on database :P Off course RigManager is API for users to change the tags but having ability to run SQL script over database it would make tagging and naming very convenient.

  • Whateven sysex is it's not updated by update on database :P Off course RigManager is API for users to change the tags but having ability to run SQL script over database it would make tagging and naming very convenient.

    In kipr files there are sysex MIDI messages with rig names and tags.
    RM is taking care of update this messages whhen you are sending rigs to the KPA or editing them.
    KPA take care of this messages whhen you are saving a rig.

    Your SQL database editor will not do this !!!! Thats all.

    The RM uses SQL database but it have their own algorithm to manage the RIG Internal data structure.

  • My problem is that the tagging of the rigs is really inconsistent (although I can understand what legal boundary conditions lead to it). But I do neither want mangled or phantasy names on my Kemper nor being forced to do a manual change.


    that's just fair. we don't like fake names either.
    gs

    Get in touch with Profiler online support team here

  • This is a dangerous mixture of being curious, overconfident and childish. Using SQL manipulation of data without knowing the relations and other related stuff will most likely lead to unexpected and random errors that no1 can reproduce.

    Yet when your precious database will go down in flames, you're gonna blame it on the company and its "inferior programming".

    Do I wish there was a more complex search or a few extra user tags or the possibility of saving searches as a view - yes I do. But this is not the proper way to overcome any current limitation of RM.

    90% of the game is half-mental.

  • This is a dangerous mixture of being curious, overconfident and childish. Using SQL manipulation of data without knowing the relations and other related stuff will most likely lead to unexpected and random errors that no1 can reproduce.

    Yet when your precious database will go down in flames, you're gonna blame it on the company and its "inferior programming".

    Do I wish there was a more complex search or a few extra user tags or the possibility of saving searches as a view - yes I do. But this is not the proper way to overcome any current limitation of RM.

    Cannot agree. I live along with databases since long time and I do not find it childish. What's more I know the relations, they are pretty simple (for me at least). And I would not blame company for I would have done myself, never.

    What I find strange is database without any kind of authentication :)

  • It will remain dangerous whether you agree or not. :-)"
    It is also not about your technical knowledge - I have been programming databases since my early days in college too - it is about what you may NOT know in the particular context of RM.

    90% of the game is half-mental.

  • Dear bigHF,

    to be honest I found your qualification »dangerous mixture of being curious, overconfident and childish« patronizing.
    In my initial post I absolutely warned that direct database modifications are last resort measures and I guess most
    posters here are quite aware of that risk.

    And we are not talking about a complex database schema in RM: two flat tables with no relation at all. So
    almost no risk that tricky integrity constraints may apply. The only complication comes from the fact that those
    tables are denormalized, because the blobs contain data redundantly (already available in other fields).

    Fine, this is Kemper's design decision, bad luck for us.

    You tell us that »this is not the proper way to overcome any current limitation in the RM«, but you leave
    open how to overcome those limitations, especially when the limitations often depend on the interests of the
    user. My solution has been a feature request for a simplistic API for the RigManager that maintains the
    integrity of the data.

    So what is your idea?

    Best regards,

    DrTT