Query using the Microsoft Text Driver throws error [42000][-1809]

[GStegemann]

Hi Edwig,

attempting to perform a query, just a SELECT, from a table using the Microsoft Text Driver throws the following error:

SELECT lotId , state , qty ,p, rk , sortReal , queueTime , location FROM "DispatchList_64_GU" WHERE ..... : Error in SQL statement: ODBC-call returned [-1] : [42000][-1809][Microsoft][ODBC Text Driver] Aktualisieren nicht möglich; Datenbank oder Objekt ist schreibgeschützt.

Why does the ODBCQueryTool needs write access for this query?

This issue is related to issue #20.

Best regards,
Gerhard

[edwig]

I have trouble reproducing this error. I always get an answer. Even if I write-protect the file or the complete directory, always the driver gives me the right results and the error never surfaces. (This is regardless of the fixing of the error in #20)

But as it turns out: if I try to open the file in more than ONE querytool, i get the following error in the 64-bits version:

Error in SQL statement: ODBC-call returned [-1] : [HY000][-1032][Microsoft][ODBC Text Driver] The Microsoft Access database engine cannot open or write to the file '(unknown)'. It is already opened exclusively by another user, or you need permission to view and write its data.

So in order to be able to use the datasource the "Microsoft ODBC Text driver" checks that it has both read access and that the file is NOT opened in exculsive access by another program. I suggest that it does this because otherwise two querytools would be able to write to it and confuse the other program.

The definitive answer must than be: Simply because the Microsoft team designed the driver to behave this way for our own stability of the programs.

[GStegemann]

I will re-test this while monitoring the process using Procmon to see what effectively causes the error.

I'm aware of the "exclusive access" issue. On the 32 bit platform the same error message is thrown as you have seen on the 64 bit platform.

As far as I remember there was no other tool accessing the file.

Maybe the issue is related to the test environment: I performed the test under Windows Server 2008 R2. I will try the test under Windows Server 2016/2019 again.

With "related to issue #20" I meant that this issue used the same setup.

[GStegemann]

I re-tested the above query and created an ODBC trace file.

ODBCQuery_Tool_SQL.zip

In Procmon trace the following errors occured:

15:00:39,5598075 ODBCQueryTool.exe 3124 RegQueryKey HKLM SUCCESS Query: HandleTags, HandleTags: 0x0 15:00:39,5598168 ODBCQueryTool.exe 3124 RegQueryKey HKLM SUCCESS Query: Name 15:00:39,5598279 ODBCQueryTool.exe 3124 RegOpenKey HKLM\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines ACCESS DENIED Desired Access: Read/Write 15:00:39,5598623 ODBCQueryTool.exe 3124 RegQueryKey HKLM SUCCESS Query: HandleTags, HandleTags: 0x0 15:00:39,5598689 ODBCQueryTool.exe 3124 RegQueryKey HKLM SUCCESS Query: Name 15:00:39,5598774 ODBCQueryTool.exe 3124 RegOpenKey HKLM\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines ACCESS DENIED Desired Access: Read/Write 15:00:39,5600647 ODBCQueryTool.exe 3124 QueryOpen D:\zr-appl\dispatche\DispatchList_64_GU SUCCESS CreationTime: 12.02.2026 17:13:31, LastAccessTime: 12.02.2026 17:13:31, LastWriteTime: 13.06.2019 17:20:02, ChangeTime: 12.02.2026 12:05:33, AllocationSize: 221.184, EndOfFile: 218.184, FileAttributes: A

Runing the test with the 64 bit Text Driver returns the same error.

[GStegemann]

After performing more tests I think the error occurrs due to a mismatch between the DSN and the table name used in the query.

The DSN is configured for text files with extension "txt" or "asc". But due to the error described in issue #20 I used for further tests a table name without extension. And that combination seems not to be supported.