Karaoke Forums

Get a copy of Microsoft Access and open the Karma database. The history is in a separate table. Even before, when Karma used XML files, it was in separate XML files (which are tables). That's just a given that it has to be in a separate table. Before the 2015 version, if you renamed a file, it still wouldn't play it from history because it couldn't find it. The only difference now is that when you update the database and it can't find the original file, it's record is deleted. Personally, I'd rather not have records in my history that don't work. They're like useless garbage. That being said, how is your solution any easier? One way or another, you're going to be told that it can't play the file. It doesn't matter if it's highlighted in a different color or just not there. Either way, you still need to re-lookup the song for the singer. It's actually better now because of the relational database. It's what enables you to edit the file name in Karma and then have it automatically update all the related history records so instantly. It's also what enables accurate reports. If it left lingering records of old file names, it would completely make the reports inaccurate. Sure, Bob could write even more extra code to have it scan for every file before running reports, but that would be ridiculous, and the people who CAN follow the rules should not be penalized for the bad habits of those who can't. Personally, I'm glad Bob sticks to his guns. If he listened to you guys, we'd still have a program that used XML files for data storage and he would be spending his time writing code to compensate for all of your mistakes and bad habits.

Speaking of bad habits, let's not forget the fact that Karma's help file has, as far back as I can remember, informed us that renaming files outside of the program was NOT recommended, so it's not like you can claim that you were caught off guard (even though you are). You didn't follow the rules, and now you want the manufacturer to compensate for your inability to read? Really? If you step on the gas pedal instead of the brake, you can't sue the auto maker (or even have the right to complain) when you crash into a tree just because YOU thought it should be setup differently.

Of course they 'recommend' you don't change the file names outside the program. You'll potentially lose history if you do! How about a separate history table? PROBLEM SOLVED. It's NOT useless garbage to everyone. It's HISTORY. How about we change or delete facts from (pick a history event) because we want move them to a different chapter or different part of the book? *The events still happened.* How about the developer not be so lazy and start listening to people that actually use the program that are outside his 'yes men' circle of users who say, 'oh yes, that's exactly what I would do. Oh yes, you're right, Mr. Bob.'

Get a copy of Microsoft Access and open the Karma database. The history is in a separate table. Even before, when Karma used XML files, it was in separate XML files (which are tables). That's just a given that it has to be in a separate table. Before the 2015 version, if you renamed a file, it still wouldn't play it from history because it couldn't find it. The only difference now is that when you update the database and it can't find the original file, it's record is deleted. Personally, I'd rather not have records in my history that don't work. They're like useless garbage. That being said, how is your solution any easier? One way or another, you're going to be told that it can't play the file. It doesn't matter if it's highlighted in a different color or just not there. Either way, you still need to re-lookup the song for the singer. It's actually better now because of the relational database.

Not sure why it's so hard to do. MTU Hoster has their history set up in a separate data file so it doesn't matter if you move, rename, delete any file. Even if i deleted the entire database, I can still print history reports of everything ever sung and by whom. Can add an entirely new database on a different drive path and the history will continue where it left off and since the history file has nothing to do with current databases, nothing will show up in a current data search that isn't active, renamed, moved or whatever.

Widgets, Wajits, and the IRS . . .

IRS: Our records show you purchased 1million widgets last year, sold 500 thousand of them, and paid inventory tax on the other 500 thousand.
We show you also purchased 1 million wajits but you show zero sold, and zero in inventory . . .
Sounds fishy to us.

Bobcom: Oh, we moved all those purchased wajits from our Chicago warehouse to our Tampa warehouse so our computer software deleted all the inventory and sales records for them.

IRS: uhhhh What?

Oh, no no no. Bad analogy. They'll all be bad analogies because the programmer is lazy.

Widgets, Wajits, and the IRS . . .

IRS: Our records show you purchased 1million widgets last year, sold 500 thousand of them, and paid inventory tax on the other 500 thousand.
We show you also purchased 1 million wajits but you show zero sold, and zero in inventory . . .
Sounds fishy to us.

Bobcom: Oh, we moved all those purchased wajits from our Chicago warehouse to our Tampa warehouse so our computer software deleted all the inventory and sales records for them.

IRS: uhhhh What?

Good database design does not make the existence of a record dependent on where the corresponding file is located in the file system.

Each file should be assigned a serial number that relates to characteristics that can be determined by examining the file—file size, file name, ID3 tag, etc.—so that a scan of this information will allow the location of the file to be determined even if it's moved. Then singer records would refer to the serial number, and you would not lose records.

Duh.

MTU Hoster has ALWAYS done exactly that... since day 1. The song is assigned a "serial number" and "header information" (think of it as an id3 tag) contains the details.

And it's called the "BookID" So it doesn't matter if you move the song or not, it always contains the proper information.

My "serial numbers" for the DK series coincides exactly with the original disc & track numbers so song # 5601 is disc 56 track 01: "My Girl" by the Temptations. Since I had all the disc/track numbers (involuntarily) memorized anyway, it made a lot of sense.

waiting to see your own hosting design Chris. who better than a host to design it?

waiting to see your own hosting design Chris. who better than a host to design it?

No I wouldn't say he's lazy, anyone who can create a successful software isn't lazy. However thinking HIS way is the ONLY way a show should be run is pretty f'd up. Making people feel like idiots on service calls. Taking away features that people liked and used. Not listening to kj feature requests because he doesn't think a kj really needs them (even though they really want them). Banning people from their FB pages because they question him or ask about things. Deleting licenses because people ask for support and may not understand or get defensive when he starts going off on them about being stupid (many forum posts about that).

Almost willing to bet that as soon as Bob finds out there are add on's to his program he will start deleting licenses for those using the add on. That's just his way of doing business.

Almost willing to bet that as soon as Bob finds out there are add on's to his program he will start deleting licenses for those using the add on. That's just his way of doing business.