SQL Anywhere on Windows operating system changes db file to read only

[Breck_Carter]

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?

[Breck_Carter]

Why do you want to stop this from happening? There may be another way to accomplish what you need.

[Breck_Carter]

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 🙂

[VolkerBarth]

I fully agree!

Though the read-only "protection" is not that strong - I remember cases of users who had used yet another clean-up tool on their box, and sadly enough, ".log" files were considered unnecessary... - and so their (previously well-behaving) SQL Remote databases were doomed to fail:)

[Breck_Carter]

Does everyone have a SQL-Remote-deleted-log story to tell?

I remember working at a contractor supplying services to a Top 5 Chartered Bank in Canada where the IT guy deleted the V5.5 consolidated database transaction log, and the resulting re-extract of all the remotes required the purchase of an extra server to complete in a timely manner. It was a humbling experience for that guy. Everyone else was silently "glad I'm not him". In that case, read only would have made no difference whatsoever 🙂

[VolkerBarth]

And no backup of the consolidated was available, so only a few "lately active" remotes would have had to be re-extracted? What a PITA:(

Hm, what about a "nostalgia" tag?