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.

How do I change the ODBC driver back to ODBC Driver 17?

Which ODBC driver do you now have installed? ODBC 18? If so, I'm surprised to learn that it doesn't fix the problem with PK's. To "roll back" the driver, though, you simply install the other version, ODBC 17, the same way you installed ODBC 18 on all of the computers which use your accdb. Then relink the tables in the SQL Server database to your Access accdb using that driver. Finally, distribute this version of the accdb to all users.

Me too am having same problem. Version 2205 update is the culprit. Any table with varchar as primary keys are affected with the #Deleted problem. Rolling my Office 365 back to version 2204 has fixed this for now. I'm using ODBC MySQL connector for my linked tables. Microsoft please fix this asap as this is a critical problem. I've many clients affected and not being able to access their database!

If you change the tables in SQL Server then you should also change all the one to one or one to many relationships or suffer timeouts and sever degradation in linked tables. i

I'm not changing anything. I'm using MySQL. The problem now is Office version 2205 is breaking the ODBC. Linked tables with varchar as primary keys can't be read out of sudden! This is a critical Microsoft problem.

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-30T10:45:17+00:00

How do I change the ODBC driver back to ODBC Driver 17?
Was this answer helpful?

0 comments No comments
George Hepworth 23,120 Reputation points Volunteer Moderator

2022-05-30T13:26:40+00:00

Which ODBC driver do you now have installed? ODBC 18? If so, I'm surprised to learn that it doesn't fix the problem with PK's.

To "roll back" the driver, though, you simply install the other version, ODBC 17, the same way you installed ODBC 18 on all of the computers which use your accdb. Then relink the tables in the SQL Server database to your Access accdb using that driver. Finally, distribute this version of the accdb to all users.
Was this answer helpful?

1 person found this answer helpful.

0 comments No comments
Anonymous

2022-05-31T01:03:28+00:00

Me too am having same problem. Version 2205 update is the culprit. Any table with varchar as primary keys are affected with the #Deleted problem. Rolling my Office 365 back to version 2204 has fixed this for now. I'm using ODBC MySQL connector for my linked tables. Microsoft please fix this asap as this is a critical problem. I've many clients affected and not being able to access their database!
Was this answer helpful?

2 people found this answer helpful.

0 comments No comments
Anonymous

2022-05-31T01:24:18+00:00

If you change the tables in SQL Server then you should also change all the one to one or one to many relationships or suffer timeouts and sever degradation in linked tables. i
Was this answer helpful?

0 comments No comments
Anonymous

2022-05-31T02:05:20+00:00

I'm not changing anything. I'm using MySQL. The problem now is Office version 2205 is breaking the ODBC. Linked tables with varchar as primary keys can't be read out of sudden! This is a critical Microsoft problem.
Was this answer helpful?

4 people found this answer helpful.

0 comments No comments