Hello,
This issue is appearing at a client whose security protocol do not allow me to connect to their server.
Randomly during the day, we face a case whereby a dataset raises the "cannot modify a read-only dataset".

Unticking the "read-only" flag in EDBMgr resolves the issue temporarily, until the same occurs on another dataset.
With the help of their IT, we went in and verified that all those files are granted full-access to those who need to use it (checked all blob / tbl / idx extensions).

I went as far as, upon starting of the application, verify that all datasets are NOT read-only, and programmatically remove the restriction from any that *are* read-only.

Today, the client has been operating for 48 minutes according to MadExcept, and he gets this error again.

The docs state: "if any of the physical files that make up a table are marked read-only at the operating system level (such as is the case with CD-ROMs) then ElevateDB automatically detects this condition and sets the ReadOnly property to True."

I don't know and will not be able to know if this is mis-firing, or whether there is something unbeknown to me causing this detection to occur.

Any suggestion, other than periodically checking every 1min or so whether there are any tables in read-only?

Thanks!

Fady


It sounds like a permissions problem. Is the folder/directory the tables are in being set to read-only? Is the server Linux based and being accessed over SAMBA? I've had a few problesm with the latter.

Roy Lambert

Hello Roy,

it is a Windows server, and over screen-share, they showed me that the data-folder had full-permissions to all files.
What's interesting is, every now and then, a random table gets toggled as read-only inside ElevateDB.

worth noting that the program runs on file-based EDB and not client-server.
The Session Log only shows that a cursor had an error attempting to open a read-only file, but unfortunately does not log at which point said table was set in read-only and why

<<
Fady Geagea wrote:

it is a Windows server, and over screen-share, they showed me that the data-folder had full-permissions to all files.
What's interesting is, every now and then, a random table gets toggled as read-only inside ElevateDB.

worth noting that the program runs on file-based EDB and not client-server.
The Session Log only shows that a cursor had an error attempting to open a read-only file, but unfortunately does not log at which point said table was set in read-only and why
>>


Does an existing table (that was confirmed to be read-write) suddenly change to read-only or are you referring to query results being read-only ?

Does app allow one to create new tables (either from scratch new or using sql select into type logic) ?

Do all user have same permissions to the file share?

I would check things like TempTablesPath as well since it might inherit read-only flag from its folder.

Raul

Raul wrote:

<< Does an existing table (that was confirmed to be read-write) suddenly change to read-only or are you referring to query results being read-only ?

Does app allow one to create new tables (either from scratch new or using sql select into type logic) ?

Do all user have same permissions to the file share?

I would check things like TempTablesPath as well since it might inherit read-only flag from its folder. >>


Hi Raul, thanks for the suggestions.  Please find my replies below:

- Yes, many existing tables were read-write and became read-only all of a sudden, and not necessarily at the same time.
- the application itself can create any missing tables, properly define its fields etc...  but there is no need for the end-user / database admin to interfere.  Everything is fully automated, and working fine at maybe around 40 clients (different installations).
- all Windows users are part of the same group as I was shown.
- Note that I am currently checking programmatically on startup if any table is marked as read-only (EDB, not OS file), and removing this restriction: so if a user truly had limited access at OS level, they would never be able to operate at all, instead of it being a random occurrence - sometimes they can, and sometimes it's read-only.
- the TempTablesPath is also used separately by the application to write other things, so I would have gotten an OS IO error elsewhere if it was truly restricted.

I'm running out of ideas.  Can't I opt out of the automatic EDB read-only detection, so the client can get a native OS error, thus narrowing down the scope of the issue?

Fady


<<Everything is fully automated, and working fine at maybe around 40 clients (different installations).>>

To me this says its far more likely to be related to the clients particular installation than ElevateDB or that they are doing something different from your other clients eg very long queries.

Things that come randomly to mind:
AV software
Network configuration
Overnight backups

Roy Lambert

Roy Lambert wrote:

Fady


<<To me this says its far more likely to be related to the clients particular installation than ElevateDB or that they are doing something different from your other clients eg very long queries.

Things that come randomly to mind:
AV software
Network configuration
Overnight backups>>

I do agree with you, that the issue is specific to their site, but unfortunately I don't have access to their network to prove, disprove or alter anything :/
Hence the question: is there a way to ask EDB not to do smart-readonly detection, and let the files be?  

Fady


>I do agree with you, that the issue is specific to their site, but unfortunately I don't have access to their network to prove, disprove or alter anything :/
>Hence the question: is there a way to ask EDB not to do smart-readonly detection, and let the files be?

I don't know of one, the best person to ask is Tim directly. My thoughts are that if you have the source you could try modifying it BUT I think ElevateDB uses calls to Windows routines (I'm pretty sure DBISAM did but I'm not positive about ElevateDB) so trying to write to some dataset may fail anyway.

One thought has just crossed my mind - not a "proper" cure but it might help. Subclass the TEDBTable and TEDBQuery and override the BeforeOpen event to check if the table / datasets are in read-only mode and if so alter it.

Roy

<< Fady Geagea wrote:

I do agree with you, that the issue is specific to their site, but unfortunately I don't have access to their network to prove, disprove or alter anything :/
Hence the question: is there a way to ask EDB not to do smart-readonly detection, and let the files be?  

>>

The only other thing that came to mind is to check share vs disk permissions for users - you mentioned this is using file share access so make sure IT has given full control for the share and file system (not sure which one they showed you).

however considering you can uncheck the read-only option means at that point permissions are OK so i would concur that best to email support (Tim) directly

Raul