SQL Anywhere on Windows operating system (Windows 7) changes the db file to read only after whichever process that starts the server is ended. For example: open a db from Sybase Central, after Sybase Central exit, the db file is changed to read only.
Does anyone know how to stop this from happening?
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 (firewalls, security settings, etc) on personal productivity, so for me to actually *like* a limitation is a big deal indeed :)
answered 17 Jul '13, 06:22
That's expected behaviour - on all platforms, methinks:
Database files (including the log files) created by SQL Anywhere are read-only by default - AFAIK, in order to prevent unintended deletion.
When the database is started on a database engine, the read-only attribute of the according files is cleared but now these files are locked by the database engine process and cannot be deleted by other processes. When the database is closed, the read-only attribute is set again.
Therefore, for "valuable data", that behaviour seems very reasonable to me. Apparently, you can use "ATTRIB -r" or similar commands to remove the read-only attribute.