Read Only Rant

Sometimes ya gotta nip a Feature Request in the bud, while it's still in the form of question "How do I [do some thing]?"

Here's an example: "How do I stop SQL Anywhere from marking database files as read only?"

Without quick action that might morph into a change request, hence this rant...

---

This is a possible answer to a different question, "Why does SQL Anywhere mark the database file as read only?"

The original reason(s) may be lost in the sands of time since SQL Anywhere has always done that, so let's change the question:

Why do *I* want SQL Anywhere to mark the database file as read only?

Answer: Because SQL Anywhere files are often used very differently from other products' files. Unlike (for example) SQL Server databases, it is extremely easy to create SQL Anywhere databases, and copy and move them around, even across hardware and software platforms. SQL Anywhere files are binary compatible across big endian and little endian computers, for example... Windows, Linux, Sparc, AIX, mobile, whatever.

SQL Server (and Oracle, and ASE, and IBM) databases tend to get created once and sit in the same place forever and ever. Some of them (historically, at least) aren't even operating system files, they are magical low-level "native files" that are profoundly difficult to move around.

Yes, that is a stereotypical view of databases... BUT historically speaking, it is true. For example, it is a very rare thing for a programmer to have one or two or ten separate SQL Server (or, gasp, Oracle) databases... but it is a very common thing for SQL Anywhere. Speaking personally (as a possible outlier :) I have literally thousands of SQL Anywhere .db files on my laptop, of all versions from 5.5 through 16... nothing in the product discourages me from doing that.

And in the real world, mobile replication and synchronization makes it possible for a single SQL Anywhere production system to encompass tens of thousands of separate SQL Anywhere database files.

File proliferation comes with it's own hazards, and accidental overwrite is one of them. The read only attribute is one mechanism to help guard against that.

The read only attribute is much easier to deal with than, say, SQL Server's approach to protecting their .mdf files...



In conclusion: The read only attribute is a minor annoyance that has saved me from making mistakes on many occasions. Folks who know me, know how much I loathe restrictions on personal productivity (firewalls, security settings, etc), so for me to actually *like* a limitation is a big deal indeed :)