tags:

views:

65

answers:

1

If "read only" is checked in the Windows desktop properties for a .dbf or .mdb file, and a Delphi 6 ADO connection (say, via Jet for an .mdb file or ODBC for a .dbf file) is then used to open that database, TADOTable.CanModify returns true and TADOTable.ReadOnly returns false, apparently failing to detect the file is actually read-only.

From the VCL source, it looks like .CanModify is just set from Supports(xUpdates) and .ReadOnly is set from the LockType (even "read-only data source" in TADOConnection.Properties returns 0), so those properties seem more like tools for detecting connectionstring options as opposed to detecting the database's original read-only state.

So what's the proper ADO technique to detect a database is marked read-only before TADOTable.Edit is attempted? Seems the solution should not be specific to Windows files, but some kind of database-independent technique using just ADO. What's the solution?

A: 

It's a pity, but you can't.

However, since the filename is part of the connection string, you can check yourself.

--jeroen

Jeroen Pluimers
@Jeroen: for a .txt or .dbf file, the connection string might name only the "database" (the parent folder) and the file is the table (possibly independently marked read-only). hence, you have to check at both levels (the file named in the connection string for some databases, or the table itself for other kinds of databases).
Les Paul