#Deleted error

Steve in Atlanta

New Member
Joined
Jun 16, 2004
Messages
31
Can anyone explain why I might be getting this error and how to eliminate it? I am running a select query comparing a table in access to a linked ODBC table. I am joining the two tables on social security numbers and I am returning two fields from the linked table (session and completed). I only want the sessions where completed is blank (has not completed that session). When I run the query where completed = " " some of the values that are returned say "#Deleted". It does return some of the values, though (see below).

SSN SESSION COMPLETED
#Deleted #Deleted
#Deleted #Deleted
#Deleted #Deleted
#Deleted #Deleted
H
#Deleted #Deleted
K
L

It also displays the ssn (which I have removed) for every row.

Any ideas?
 

Excel Facts

When they said...
When they said you are going to "Excel at life", they meant you "will be doing Excel your whole life".
#Deleted can be the sign of a corrupt database. Try running Compact and Repair (Tools | Database Utilities) and have another look.

Denis
 
Upvote 0
Following on from Denis, are you able to verify the data in the linked ODBC table that is giving you trouble? Can you look at the data from another system to check what values exist for "session" and "completed" for the troublesome ssn's?

Also, does the data in the linked table conform to the " " you mentioned in your post? Or should you be testing for null records?

Andrew.
 
Upvote 0
I've found that if you run a delete query while having a table open, the records that you delete start displaying the #Deleted flag as they are deleted by the query. Could it be users of the SQL database deleting data while you are processing?

Cal
 
Upvote 0
From Technet a few years ago:
Article last modified on 01-06-1998
---------------------------------------------------------------------
The information in this article applies to:

- Microsoft Access version 2.0, 7.0, 97
---------------------------------------------------------------------

SYMPTOMS
========

When you retrieve, insert, or update records in an attached ODBC table,
each field in a record contains the "#Deleted" error message. When you
retrieve, insert, or update records using code, you receive the error
message "Record is deleted."

CAUSE
=====

The Microsoft Jet database engine is designed around a keyset-driven model.
This means that data is retrieved, inserted, and updated based on key
values (in the case of an attached ODBC table, the unique index of a
table).

After Microsoft Access performs an insert or an update of an attached ODBC
table, it uses a Where criteria to select the record again to verify the
insert or update. The Where criteria is based on the unique index.
Although numerous factors can cause the select not to return any records,
most often the cause is that the key value Microsoft Access has cached is
not the same as the actual key value on the ODBC table. Other possible
causes are as follows:

- Having an update or insert trigger on the table, modifying the key
value.

- Basing the unique index on a float value.

- Using a fixed-length text field that may be padded on the server with
the correct amount of spaces.

- Having an attached ODBC table containing Null values in any of the
fields making up the unique index.

These factors do not directly cause the "#Deleted" error message. Instead,
they cause Microsoft Access to go to the next step in maintaining the key
values, which is to select the record again, this time with the criteria
based on all the other fields in the record. If this step returns more than
one record, Microsoft Access returns the "#Deleted" message because it does
not have a reliable key value to work with. If you close and re-open the
table or choose Show All Records from the Records menu, the "#Deleted"
errors are removed.

Microsoft Access uses a similar process to retrieve records from an
attached ODBC table. First, it retrieves the key values and then the rest
of the fields that match the key values. If Microsoft Access is not able to
find that value again when it tries to find the rest of the record, it
assumes that the record is deleted.

RESOLUTION
==========

The following are some strategies that you can use to avoid this behavior:

- Avoid entering records that are exactly the same except for the unique
index.

- Avoid an update that triggers updates of both the unique index and
another field.

- Do not use a Float field as a unique index or as part of a unique index
because of the inherent rounding problems of this data type.

- Do all the updates and inserts by using SQL pass-through queries so
that you know exactly what is sent to the ODBC data source.

- Retrieve records with an SQL pass-through query. An SQL pass-through
query is not updateable, and therefore does not cause "#Delete" errors.

- Avoid storing Null values within any field making up the unique index of
your attached ODBC table.

MORE INFORMATION
================

Steps to Reproduce Behavior
---------------------------

1. Open the sample database Northwind.mdb (or NWIND.MDB. in Microsoft
Access 2.0)

2. Use the Upsizing Tools to upsize the Shippers table.

NOTE: This table contains an AutoNumber field (or Counter field in
Microsoft Access 2.0) that is translated on SQL Server by the Upsizing
Tools into a trigger that emulates a counter.

3. Open the attached Shippers table and enter a new record. Make sure
that the record you enter has the same data in the Company Name field
as the previous record.

4. Press TAB to move to a new record. Note that the "#Deleted" error fills
the record you entered.

5. Close and re-open the table. Note that the record is correct.

Additional query words: pounddeleted mcsys7 kbinterop kb3rdparty
=====================================================
Keywords : OdbcOthr kberrmsg kbinterop
Version : 2.0
Platform : WINDOWS
Hardware : x86
Issue type : kbprb
Solution Type : Info_Provided
=====================================================
Copyright Microsoft Corporation 1998.
 
Upvote 0
Thanks to everyone!

When I query the ODBC database directly using SQL everything seems to be ok. When using the access query some of the rows that have the completed field empty return the #Deleted error and others don't. I can't notice any difference between the two when looking at it using SQL.

When I run the query looking for null records it does not return any rows.

Interestingly, when I run the query as a make table query it populates the table correctly (does not return any #Deleted errors). Is a make table query considered a 'pass-through' query as suggested in the 'Resolution' section of klb's reply?
 
Upvote 0

Forum statistics

Threads
1,221,825
Messages
6,162,165
Members
451,750
Latest member
dofrancis

We've detected that you are using an adblocker.

We have a great community of people providing Excel help here, but the hosting costs are enormous. You can help keep this site running by allowing ads on MrExcel.com.
Allow Ads at MrExcel

Which adblocker are you using?

Disable AdBlock

Follow these easy steps to disable AdBlock

1)Click on the icon in the browser’s toolbar.
2)Click on the icon in the browser’s toolbar.
2)Click on the "Pause on this site" option.
Go back

Disable AdBlock Plus

Follow these easy steps to disable AdBlock Plus

1)Click on the icon in the browser’s toolbar.
2)Click on the toggle to disable it for "mrexcel.com".
Go back

Disable uBlock Origin

Follow these easy steps to disable uBlock Origin

1)Click on the icon in the browser’s toolbar.
2)Click on the "Power" button.
3)Click on the "Refresh" button.
Go back

Disable uBlock

Follow these easy steps to disable uBlock

1)Click on the icon in the browser’s toolbar.
2)Click on the "Power" button.
3)Click on the "Refresh" button.
Go back
Back
Top