We use an ODBC connection to bring some tables from a vendor supplied database into MS Access so that users can create their own on demand queries without needing to know SQL. Some of those tables, not all of them, have started to have problems in MS Access so that every field is populated with #Deleted when we try to open the table. We can query these tables fine using pl/sql Developer. 3 tables that are working have num datatypes for primary key(s). 3 tables that are not working use a combination of num and char datatypes as the primary keys. No bigint datatypes in these tables. There are no pending deletes on the 3 tables that are not working. Since the tables are vendor delivered, we can't change the data structure. A combination of Oracle driver 12.01.00.02 or 12.02.00.01 and MS Access version 2112 build (14729.20194) - the 3 problem tables all show #Deleted in all fields. A combination of Oracle driver 12.02.00.01 and MS Access version 2111 build (14701.20240) - the 3 problem tables work properly and show the data in all fields. This seems to indicate that the problem is with the version of MS Access. I've been looking for other reports of #Deleted and what I can find are from 6 or 7 years ago and not very many are recent reports. Does anyone have an idea for a workaround? We hate to lose the ability for our users to utilize MS Access for querying these tables.

This problem started for me on 27/5/22. Changing the driver to ODBC Driver 17 for SQL Server fixed the problem. ODBC Driver 18 for SQL Server wouldn't work for me.

Perhaps not 100% related but I too was having a number of tables with all fields and all records shown as "#Deleted" when opened via the regular MS Access data form using a MariaDB database and a MariaDB ODBC driver. The problem first appeared after installation of the Microsoft 2022-05 release and running MS Access 2205. In my case the problem was caused by MS Access automatically selecting the last index defined in the MariaDB as unique as the primary key to use in MS Access, as opposed to the index I have specifically defined as the primary key in MariaDB. The index selected by MS Access contained multiple fields and for some reason did not work for MS Access. After I had removed the unique predicate from all other indexes (i.e. I kept the index but removed the unique classification in MariaDB), and refreshed the link to the table in MS Access, my problem was solved.

Perhaps not 100% related but I too was having a number of tables with all fields and all records shown as "#Deleted" when opened via the regular MS Access data form using a MariaDB database and a MariaDB ODBC driver. The problem first appeared after installation of the Microsoft 2022-05 release and running MS Access 2205. In my case the problem was caused by MS Access automatically selecting the last index defined in the MariaDB as unique as the primary key as opposed to the index I have defined as the primary key. The index selected by MS Access contained multiple fields and for some reason did not work for MS Access. After I had removed the unique predicate from all other indexes and refreshed the link in MS Access, my problem was solved. Good morning , I have the same problem. With the access version 2205. We also have some access of another version in the company and they continued to work well. In my case it is obc to access PostgresSQL . I hope they fix it in the next version. I can't do without the indices and I had to go to 2204.

We had the same problem with our FE/BE environment. Since updating the database wasn't an option we rolled back Access to version 2204 and that is working for the moment. Hopefully this can be fixed in future versions!

MS Access Displays #Deleted in Every Field for Certain Tables

Anonymous

We use an ODBC connection to bring some tables from a vendor supplied database into MS Access so that users can create their own on demand queries without needing to know SQL. Some of those tables, not all of them, have started to have problems in MS Access so that every field is populated with #Deleted when we try to open the table. We can query these tables fine using pl/sql Developer.

3 tables that are working have num datatypes for primary key(s).
3 tables that are not working use a combination of num and char datatypes as the primary keys. No bigint datatypes in these tables.
There are no pending deletes on the 3 tables that are not working.
Since the tables are vendor delivered, we can't change the data structure.
A combination of Oracle driver 12.01.00.02 or 12.02.00.01 and MS Access version 2112 build (14729.20194) - the 3 problem tables all show #Deleted in all fields.
A combination of Oracle driver 12.02.00.01 and MS Access version 2111 build (14701.20240) - the 3 problem tables work properly and show the data in all fields.

This seems to indicate that the problem is with the version of MS Access. I've been looking for other reports of #Deleted and what I can find are from 6 or 7 years ago and not very many are recent reports. Does anyone have an idea for a workaround? We hate to lose the ability for our users to utilize MS Access for querying these tables.

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

54 answers

Anonymous

2022-05-30T03:45:12+00:00

This problem started for me on 27/5/22. Changing the driver to ODBC Driver 17 for SQL Server fixed the problem.

ODBC Driver 18 for SQL Server wouldn't work for me.
Was this answer helpful?

0 comments No comments
Anonymous

2022-05-30T06:36:51+00:00

Perhaps not 100% related but I too was having a number of tables with all fields and all records shown as "#Deleted" when opened via the regular MS Access data form using a MariaDB database and a MariaDB ODBC driver.

The problem first appeared after installation of the Microsoft 2022-05 release and running MS Access 2205.

In my case the problem was caused by MS Access automatically selecting the last index defined in the MariaDB as unique as the primary key to use in MS Access, as opposed to the index I have specifically defined as the primary key in MariaDB. The index selected by MS Access contained multiple fields and for some reason did not work for MS Access.

After I had removed the unique predicate from all other indexes (i.e. I kept the index but removed the unique classification in MariaDB), and refreshed the link to the table in MS Access, my problem was solved.
Was this answer helpful?

0 comments No comments
Anonymous

2022-05-30T08:41:00+00:00
Perhaps not 100% related but I too was having a number of tables with all fields and all records shown as "#Deleted" when opened via the regular MS Access data form using a MariaDB database and a MariaDB ODBC driver.

The problem first appeared after installation of the Microsoft 2022-05 release and running MS Access 2205.

In my case the problem was caused by MS Access automatically selecting the last index defined in the MariaDB as unique as the primary key as opposed to the index I have defined as the primary key. The index selected by MS Access contained multiple fields and for some reason did not work for MS Access.

After I had removed the unique predicate from all other indexes and refreshed the link in MS Access, my problem was solved.
```
Good morning ,
I have the same problem. With the access version 2205. We also have some access of another version in the company
 and they continued to work well. In my case it is obc to access PostgresSQL . I hope they fix it in the next version.
 I can't do without the indices and I had to go to 2204.
```
Was this answer helpful?

0 comments No comments
Anonymous

2022-05-30T09:49:24+00:00

We had the same problem with our FE/BE environment. Since updating the database wasn't an option we rolled back Access to version 2204 and that is working for the moment.

Hopefully this can be fixed in future versions!
Was this answer helpful?

0 comments No comments
Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more