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?

asked 17 Jul '13, 02:57

VMeng's gravatar image

VMeng
1567714
accept rate: 0%

edited 17 Jul '13, 07:08

Volker%20Barth's gravatar image

Volker Barth
30.0k294448654

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

(17 Jul '13, 05:37) 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...

alt text

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 :)

permanent link

answered 17 Jul '13, 06:22

Breck%20Carter's gravatar image

Breck Carter
27.4k425586838
accept rate: 21%

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:)

(17 Jul '13, 07:07) Volker Barth
Replies hidden
2

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 :)

(17 Jul '13, 10:55) Breck Carter

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?

(17 Jul '13, 11:07) Volker Barth

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.

permanent link

answered 17 Jul '13, 03:14

Volker%20Barth's gravatar image

Volker Barth
30.0k294448654
accept rate: 32%

edited 17 Jul '13, 03:15

3

The files are marked read-only not to prevent deletion of the files (since that can still be done - to prevent deletion the directory in which the files exist would need to be marked read-only), rather it is to prevent other applications or users from inadvertently or accidentally modifying the contents of the files. E.g. we have seen customers attempt to edit the database contents using a text editor! ... and this is never a good thing for so many reasons.

(17 Jul '13, 09:07) Mark Culp
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×37
×20
×15

question asked: 17 Jul '13, 02:57

question was seen: 2,028 times

last updated: 17 Jul '13, 11:07