If you aren't syncing your changes to the cloud server, then yes you would need to maintain your own backup regimen to ensure you don't lose data if your main machine fails.
-
Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.
If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.
- The Lone Wolf Development Team
Why is the database machine bound?
- Thread starter mantrasong
- Start date
If you aren't syncing your changes to the cloud server, then yes you would need to maintain your own backup regimen to ensure you don't lose data if your main machine fails.
I'm not completely sure if that would be correct, but I definitely don't know the full details on that. We'd need someone from Lone Wolf to confirm that part. In either case I wouldn't call that a deal breaker for me at all, though.
mantrasong
Member
Yeah, I'm waiting for someone from Lone Wolf to confirm, at this point. It's a deal-breaker for me (potentially), mostly because it implies that they are more concerned with control than the user experience/data integrity. From a "that sounds like bad DRM standpoint", it makes me reluctant to support the product.
Yeah, but that's is the point I'd been addressing all along. That, in fact, it's not only NOT from a control standpoint, but that they actually provide us with the method in which we wouldn't even need to use their servers to maintain the data file across multiple systems. That there is actually an extremely sound and standard practice reason from a practical database programming and maintenance standard for it to be set up the way that it is which has nothing at all to do with control of a product in any kind of "bad DRM standard" kind of way. The simple fact that you can click a button to do and export and pull that export one ANY system running Realm Works in and of itself belies the fact that it's some kind of control method in the way you suggest, it seems to me.
I am sorry. If you are that obsessive/compulsive about the back-up for your particular database in Realm Works.. why wouldn't you do the cloud back-up then?
you make it sound like LW has it out for you when they have given you the perfect means of backing things up in the cloud for a fairly minimum cost. But right now it just seems like you are trying to come up with some far fetched scenario and then almost "accusing" LW of not wanting to make it so that their software is not able to be backed up the way "you" want. The software is robust and strong even in the face of crashes. They are giving you the means of being able to use different computers which most databases on the market are not able to.
If you do not want that and I am not sure why you would not.. then I am not sure what to say... but you would be in a very low low percentage then.
And there's no significant difference with or without the cloud. With the cloud, you sync after changes. If you've made changes on another computer, then you sync before changes.
Without the cloud, you export your database after changes. If you've made changes on another computer, you import your database before changes. Conceptually, it's the same process. I don't understand what risk there is.
I would assume that the database is in some form of optimised mode when on a specific machine (perhaps links are stored as direct addresses onto the hard disk). This requires the optimisation to be removed when exporting and re-calculated when importing between machines.
It's generally considered very bad practice for non flat file databases to be stored on network drives, as network traffic can (and often does) cause database corruption. Most professional databases and DBAs ensure that they are running on a local drive to the database server. Since Realms Works has a database engine, it is in essence a database server and client. So this all makes sense. Why it's tied to a MoBo I don't know. But really this is an intellectual conversation more than anything else, because in reality, hard drives fail much more often than a MoBo will. So if you're going without generally backing up, you will put your own data at risk whether or not its tied to the MoBo. But Farlings idea also makes sense.
Also comparing to HeroLab isn't really appropriate. Apples and oranges. It may be made by the same company, but one application is something that reads flat files, and the other is database driven. Also, as a software and database developer I completely shudder at the thought if this WASN'T database driven. They'd have to engineer a flat file database, which are incredibly slow. It would also make cloud backup, web access, and pretty much every other feature of RealmsWorks nearly impossible.
Also comparing to HeroLab isn't really appropriate. Apples and oranges. It may be made by the same company, but one application is something that reads flat files, and the other is database driven. Also, as a software and database developer I completely shudder at the thought if this WASN'T database driven. They'd have to engineer a flat file database, which are incredibly slow. It would also make cloud backup, web access, and pretty much every other feature of RealmsWorks nearly impossible.
Last edited:
mantrasong
Member
Oh, I'm well aware that putting it on a network drive is a Bad Idea (TM). I'm actually ok with that, for the most part. Version control is hard; network access is hard; and I wouldn't blame them in the slightest for saying "Nope, we aren't willing to tackle that mess. Deal. If you try it, and mess up, it's your problem." I would be unhappy if they said, "Nope, we aren't willing to tackle that mess, and we're going to force good behaviors on you whether you want them or not."
I dislike the idea that I can't just make automatic copies of my database, like I do every other file, in a standard "backup changed files on my hard drive" backup system. While I am no database expert, it seems to me that a bit-by-bit binary backup, that I would restore post computer failure, ought to work regardless of hardware changes. If that isn't the case, it seems to be because it is designed in, and I'd like the reason why. At the end of the day, that's something I'd need to hear from a Lone Wolf staff, not speculation.
(Really, I don't think that they're out to engage in some evil DRM scheme to force me on to their cloud server, though. I have an unhealthy degree of skepticism regarding all things subscription-based that leaks through on my bad days.)
Credit where credit is due, though; zarlor has some very good answers to the not-entirely-friendly way I asked my initial question. At this point, I'm just hoping for a technical answer, before I decide whether or not I'm willing to deal with the extra backup hoops Realm Works seems to require.
Nope. I've been managing backups for years. Even with professional, enterprise level backup software (the kind that costs more than most people make in a year), you can't just do a bit-by-bit backup of any database. You need specific backup agents for specific database types, and even versions.
Now, it would be nice to have a command line interface for the database export so it can be scripted and scheduled. You could put that in the feature request. Heck, maybe I will.
As long as the bit-by-bit binary backup is performed while Realm Works is NOT running, it will be fine. You would be able to restore it without a problem. If the backup is done while Realm Works is running, expect corruption and/or crashes in Realm Works when that backup is restored.
David, I think the main part of the question he's been concerned with earlier in this thread is if you did a backup, while Realm Works was not running, that had to be restored to a different mobo/hardware, would there be an issue?
A request to the cloud server to get an ID used to generate ID's offline would be required in this case. This request doesn't require a cloud subscription and is needed so that if you ever do decide to sync to the server, there won't be any problems with ID's colliding with anyone else's ID's. That is the only purpose and it is not intended as a DRM mechanism in any fashion.
mantrasong
Member
So, just to be clear, in my particular case, this is what would be needed:
*Backup the database to wherever, when Realm Works is closed.
*<failure occurs/restore is needed>
*Restore that same copy of the database to the new/repaired computer
*Connect online to generate a new ID
Correct?
Correct.
mantrasong
Member
Awesome. Thanks David! And thanks again to zarlor/Lenny.
That is more or less the behavior I would expect, and not what the FAQ appears to say. I'm guessing that's intended to be the PR-speak for "don't do this", so I won't complain too much about it. That being said, I guess I need to go buy this now
Because I can't help but push my luck, what would happen if I did keep it on the network drive, and used two different computers to access it, as long as I'm only accessing the database from one computer at a time, presumably updating the ID as needed? (Again, all the usual caveats about how I know this is a bad idea, but I'm curious anyway)
That is more or less the behavior I would expect, and not what the FAQ appears to say. I'm guessing that's intended to be the PR-speak for "don't do this", so I won't complain too much about it. That being said, I guess I need to go buy this now
Because I can't help but push my luck, what would happen if I did keep it on the network drive, and used two different computers to access it, as long as I'm only accessing the database from one computer at a time, presumably updating the ID as needed? (Again, all the usual caveats about how I know this is a bad idea, but I'm curious anyway)
First of all, a big THANK YOU to all of the techies here who have taken the time to accurately explain the complexities of what we've already done and why putting the database on a network drive for multi-user access would be a disaster trying to happen.
Now, to clarify the concerns about the database being tied to local hardware. If you have a database on ComputerA and back it up, you can take that backup to ComputerB and restore, with NO ILL EFFECTS. If you've already logged into your account on ComputerB before doing this, everything works immediately. If ComputerB is a brand new installation that has never talked to our server, the very first thing ComputerB will require you to do is login to our server. That way, it can automatically fixup the few details that reference ComputerA in the database to now reference ComputerB - something that's done implicitly if ComputerB has already connected to our server. Once that's done, you're off and running.
As for the technical details behind this, remember that we have to be able to let users create content on multiple computers INDEPENDENTLY and OFFLINE. And we have to do this in a way that GUARANTEES that all content created on ComputerA can NEVER have an id that conflicts with content created on ComputerB. This requires that we uniquely identify each computer and coordinate that identity with our server to guarantee uniqueness. Once that's done, all new ids generated on a given computer are safely ensured to satisfy those requirements.
We key on a variety of variables to uniquely identify a given computer. If those variables change, the computer will need to contact our server to get a new "identity" value before new content can be created. Obviously, this occurs when you switch computers. However, this behavior will also occur if you're using the same machine and simply replace the network card, for example. Once the new identity is coordinated with the server, a few quick fixups are made and then you're running smoothly again, but nothing can be changed until a new "machine identity" is coordinated with the server.
There is absolutely nothing here motivated by DRM or control over how you access stuff, and it's personally very frustrating when that's the reaction many consumers have had to this architecture. In reality, it's all dictated by the desire to let users have MAXIMUM FLEXIBILITY in how and when they access their content, but we have to also guarantee that all that flexibility NEVER yields a conflict that will CORRUPT their data. It's a very difficult task that we could have simply solved by requiring users to always be online. But that wasn't our objective, and I'm very confident that allowing users to work offline is a huge benefit offered by Realm Works. The problem is that the flexibility has a trivial (IMO) cost, which is that we have to lock the client databases to specific machines in order to ensure everything works correctly.
I hope this all makes sense and helps alleviate the concerns over DRM and control.
Now, to clarify the concerns about the database being tied to local hardware. If you have a database on ComputerA and back it up, you can take that backup to ComputerB and restore, with NO ILL EFFECTS. If you've already logged into your account on ComputerB before doing this, everything works immediately. If ComputerB is a brand new installation that has never talked to our server, the very first thing ComputerB will require you to do is login to our server. That way, it can automatically fixup the few details that reference ComputerA in the database to now reference ComputerB - something that's done implicitly if ComputerB has already connected to our server. Once that's done, you're off and running.
As for the technical details behind this, remember that we have to be able to let users create content on multiple computers INDEPENDENTLY and OFFLINE. And we have to do this in a way that GUARANTEES that all content created on ComputerA can NEVER have an id that conflicts with content created on ComputerB. This requires that we uniquely identify each computer and coordinate that identity with our server to guarantee uniqueness. Once that's done, all new ids generated on a given computer are safely ensured to satisfy those requirements.
We key on a variety of variables to uniquely identify a given computer. If those variables change, the computer will need to contact our server to get a new "identity" value before new content can be created. Obviously, this occurs when you switch computers. However, this behavior will also occur if you're using the same machine and simply replace the network card, for example. Once the new identity is coordinated with the server, a few quick fixups are made and then you're running smoothly again, but nothing can be changed until a new "machine identity" is coordinated with the server.
There is absolutely nothing here motivated by DRM or control over how you access stuff, and it's personally very frustrating when that's the reaction many consumers have had to this architecture. In reality, it's all dictated by the desire to let users have MAXIMUM FLEXIBILITY in how and when they access their content, but we have to also guarantee that all that flexibility NEVER yields a conflict that will CORRUPT their data. It's a very difficult task that we could have simply solved by requiring users to always be online. But that wasn't our objective, and I'm very confident that allowing users to work offline is a huge benefit offered by Realm Works. The problem is that the flexibility has a trivial (IMO) cost, which is that we have to lock the client databases to specific machines in order to ensure everything works correctly.
I hope this all makes sense and helps alleviate the concerns over DRM and control.