No read permission on MSysObject error

The Problem (Q-score 5, ranked #43rd of 67 in the Access VBA archive)

The scenario as originally posted in 2014

I am trying to connect to an MS Access database (.mdb) through OleDb. My query is

SELECT * FROM ListQueries

which fetches me the error

SQL Execution Error.

Executed SQL Statement: SELECT * FROM ListQueries
Error Source: Microsoft JET Database Engine
Error Message: Records cannot be read; No read permission on ‘MSysObjects’.

Then I tried this answer, but it did not help. Then I saw another answer says to do this.

strDdl = "GRANT SELECT ON MSysObjects TO Admin;"
CurrentProject.Connection.Execute strDdl

I do not know how to implement that in my web project. Was writing something like this as per this suggestion by @HansUp

Alternatively, it should work from c# if you run it from an OleDb connection to the Access db

The code is,

OleDbConnection con;
using (con = new OleDbConnection(Connection.connectionString()))
{
    con.Open();
    using (var com = new OleDbCommand("GRANT SELECT ON MSysObjects TO Admin", con))
    {
        com.ExecuteNonQuery();
    }
    using (var com = new OleDbCommand("Select * from ListQueries", con))
    {
        using (var dr = com.ExecuteReader())
        {
            while (dr.Read())
            {
                qryList.Add(SQLReaderExtensions.SafeGetString(dr, "Name"));
            }
            dr.Close();
        }
    }
    con.Close();
}

The first com.ExecuteNonQuery() gives me this error.

Cannot open the Microsoft Jet engine workgroup information file.

I would really like to know how to grant permission for an OleDb call to work. Any suggestions will be wonderful

P.S: BTW, I am using MS Access 2010.

Why community consensus is tight on this one

Across 67 Access VBA entries in the archive, the accepted answer here holds niche answer (below median) status — meaning voters are unusually aligned on the right fix.

The Verified Solution — niche answer (below median) (+8)

13-line Access VBA pattern (copy-ready)

I strongly suggest that you do not use MS Access system objects. There are other and better ways to get the information.

You have a choice of ADO and DAO. Which would you prefer? Note that in ADO there is a difference between action (adSchemaProcedures) and select queries (adSchemaViews).

For example,

public static List<string> GetAllQueriesFromDataBase()
{
    var queries = new List<string>();
    using (var con = new OleDbConnection(Connection.connectionString()))
    {
        con.Open();
        var dt = con.GetSchema("Views");
        queries = dt.AsEnumerable().Select(dr => dr.Field<string>("TABLE_NAME")).ToList();
    }

    return queries;
}

When to Use It — classic (2013–2016)

Ranked #43rd in its category — specialized fit

This pattern sits in the 74% tail relative to the top answer. Reach for it when your scenario closely matches the question title; otherwise browse the Access VBA archive for a higher-consensus alternative.

What changed between 2014 and 2026

The answer is 12 years old. The Access VBA object model has been stable across Office 2013, 2016, 2019, 2021, 365, and 2024/2026 LTSC, so the pattern still compiles. Changes that might affect you: 64-bit API declarations (use PtrSafe), blocked macros in downloaded files (Mark-of-the-Web), and the shift toward Office Scripts for web-first workflows.