The cause of this problem most likely is the primary key of the table in DB2.
Access can not handle some data types as primary keys well.
Notoriously bad for PKs are all floating point numeric types. They may be rounded differently on the server and in Access. If Access uses a floating point value to query a single record from the server, there will be no results because the actual value on the server is different.This is usually the cause for the #Deleted displayed in table cells.
Good data types for Primary keys are integer types (max int32) and string/varchar types (max length 255 characters).
Dates and fixed-decimal-point data types may be causing problems as well. That is mainly dependent on the actual backend database system and the used ODBC Driver. - I have no experience in that regard with DB2.
Here are some options to solve or work around this issue
If the problem is caused by date or decimal data types in the primary key column, you should check if there are settings in you ODBC-Driver that change its behaviour for those types. If not, you could research if there is another ODBC-Driver available that is more suitable for the use with Access. Be aware that there will be data types that Access simply cannot support properly.Lacking experience with DB2 I cannot give more detailed advice on this.
The best way to solve this issue is obviously changing the structure of the base table in the server database. If you only use unproblematic data types in all the primary key columns will make the problem disappear.If Access is the primary frontend application for the database, I would strongly recommend going this way. Unfortunately there will be many scenarios where this is just not feasible.
If option 1 and 2 fail or cannot be used in your scenario, the workaround would be to create views on the server that wrap the problematic tables. You then link the views to the Access application instead of the base tables.
If you only need read only access to the data, this is a simple solution. When linking views you can (but don’t have to!) select the unique key of the view. If you don’t select any, the view will be read-only, but the data should be displayed properly.
If you do need direct write access to the data it becomes more complicated. You will need to create an artificial unique column in the view, by converting the data in the primary key column of the table to a varchar representation of the keys data. When linking the view to Access you select your artificial column as primary key. Now the data in the table should be displayed properly and should be editable (except for the key column of course).This approach will incur performance penalties for the calculated PK-column is not indexed itself. You should investigate if the database supports persisting and indexing the artificial key column in the view.
If option 1-3 cannot be used, there is another option. Do not use a linked the table (or view) at all, but create a Pass-Through-Query in Access to query the data from DB2. PT-Queries are read-only though.
If you need to edit data returned by the PT-Query, you need to send custom SQL statements to the database to update the data. So in this case this will take considerably more effort than the other options.
