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
Manipulation of RigManager Data Programmatically (BE VERY CAUTIOUS!!)
- DrTT
- Thread is marked as Resolved.
-
-
but it is not changed when
Told you so!
-
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?
gsI 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
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
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 -
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.
-
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.
