asked on

Access 2007 null values in query appear as #Deleted#

In an Access 2007 application that links SQL Server 2000 tables through ODBC I have created the following query:

SELECT OrderItems.ItemQuantity, OrderItems.ItemID, ItemComponents.ComponentQty, ItemComponents.ComponentID
FROM ((Orders INNER JOIN OrderItems ON Orders.OrderID = OrderItems.OrderID) INNER JOIN BatchControl ON (Orders.ShipDate = BatchControl.ProcDate) AND (Orders.DateBatchID = BatchControl.ProcBatchID)) LEFT JOIN ItemComponents ON OrderItems.ItemID = ItemComponents.ItemID;

Some OrderItems do not have components, and one would expect that in rows where that is the case that the values for ComponentID and ComponentQty would be null. However, they show as #Deleted#. The foreign key ItemComponents.ItemID is indexed, but not unique.

As a check I created the following simple query to see just Items and their components, and it displayed null values as expected.

SELECT ItemMaster.ItemID, ItemComponents.ComponentQty, ItemComponents.ComponentID
FROM ItemMaster LEFT JOIN ItemComponents ON ItemMaster.ItemID = ItemComponents.ItemID;

It should be mentioned that I'm using Windows 7. I don't remember ever having this type of problem with XP or Vista, but I also don't know that I ever attempted to do this exact sort of thing. It seems like I must have at one time or another, but I can't be sure.

Any help would be appreciated.

derekkromm

21.1.7.3.4: Access reports records as #DELETED# when inserting or updating records in linked tables.

If the inserted or updated records are shown as #DELETED# in the access, then:

If you are using Access 2000, you should get and install the newest (version 2.6 or higher) Microsoft MDAC (Microsoft Data Access Components) from http://support.microsoft.com/kb/110093. This fixes a bug in Access that when you export data to MySQL, the table and column names aren't specified.

You should also get and apply the Microsoft Jet 4.0 Service Pack 5 (SP5) which can be found at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q239114. This fixes some cases where columns are marked as #DELETED# in Access.

For all versions of Access, you should enable the Connector/ODBC Return matching rows option. For Access 2.0, you should additionally enable the Simulate ODBC 1.0 option.

You should have a timestamp in all tables that you want to be able to update.

You should have a primary key in the table. If not, new or updated rows may show up as #DELETED#.

Use only DOUBLE float fields. Access fails when comparing with single-precision floats. The symptom usually is that new or updated rows may show up as #DELETED# or that you cannot find or update rows.

If you are using Connector/ODBC to link to a table that has a BIGINT column, the results are displayed as #DELETED. The work around solution is:

Have one more dummy column with TIMESTAMP as the data type.

Select the Change BIGINT columns to INT option in the connection dialog in ODBC DSN Administrator.

Delete the table link from Access and re-create it.

Old records still display as #DELETED#, but newly added/updated records are displayed properly.

Smart_Systems

ASKER

derekkromm,

Thank you for your answer, but none of the above apply.

It is a select query (i.e. a read operation).
I'm using Access 2007.
There are no bigint or float fields.
Alll tables involved have primary keys.

Jeffrey Coachman

The #Deleted# (most of the time) means that the underlying dataset need to be refreshed.

First simply try refreshing the dataset.
Press Shift+F9

See this MS link as well:
http://support.microsoft.com/kb/128809

Smart_Systems

ASKER

boag2000,

Thanks for the response, but that's not it either. The data involved is all static. The issue appears to be with the combination of joins, but I know I've done such things before without this problem. The only thing that is different now is Windows 7, but I can't imagine what that has to do with it.

Jeffrey Coachman

Is this the case for all computers on Win7?
Is the Database "Split"?

All the Updates installed for Windows and Office?

Smart_Systems

ASKER

The only computer running on Win 7 is mine. I did get a chance to run the query on a couple of XP computers and got the same result (i.e. #Deleted# where nulls should appear).

The application is Access 2007 linking SQL Server 2000 tables using ODBC, so yes, it is split.

Windows and Office are current on updates.

Thanks again for your ideas.

SOLUTION

Jeffrey Coachman

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Smart_Systems

ASKER

Sorry about the absence. I was dealing with an urgent situation.

boag2000,
I have pretty much come to the same conclusion - move the data to a working table in Access, or I can change the structure (require that there be at least one component per item) so the need for the left join is eliminated. As I mentioned in my initial question, that does work. I will be at the db's site tomorrow and will test both ideas. I'll report back.

ASKER CERTIFIED SOLUTION

Smart_Systems

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Jeffrey Coachman

Click the "request Attention" link and explain what you would like to do.

;-)

Jeff

Jeffrey Coachman

OK, glad I could be of some assistance...

Congratulations on your solution as well...
;-)

Jeff

Smart_Systems

ASKER

I accepted my comment as part of the solution because it is the method I actually used. The Expert (Boag2000) proposed a method that would work, but I didn't use that method.

I gave the solution(s) a B grade because it was more of a workaround than a direct solution for the original issue. If there was a direct solution, I feel confident that one of the Experts would have known about it.