Rows showing as #DELETED

Question

I have rows of data in a table showing as #DELETED on one computer when using Access but they are fine in both the SQL database and on other computers using

Answer 1

I had a bizarre situation where a query was returning data as #Deleted, but I would run a second time (refreshing the results within the query) and the data would be correct ... sometimes. I then wrote the query results to a table to see if that would help, and the data was actually written but the rows containing foreign keys to other tables (int(11)) were returning zeros as values. The BigInt configuration in access was set (and in the odbc driver the check for binding bigint as strings was set - out of habit from previous installations).

After much reading and confusion, I decided to uninstall my ODBC 5.03.13 driver and try an older version. I happened to have a downloaded 5.03.04 msi which I installed and my database works as expected. Bizarre solution and I have no idea why it now works, but this cost me a day of work! Figure'd I'd share it, hoping this solution might help someone in case all the other suggestions on this topic are exhausted (as I had done).

Answer 2

If you are linking a table from Views on SQL, then since ROW_NUMBER() is bigint, MS Access would show #Deleted, but if you refresh a row, then it shows you the value. To overcome this, you could make use of cast. E.g.

CAST((Row_number() OVER(ORDER BY AllColumns.AnyColumnNameSuchAsDateColumn DESC)) AS INT) AS 'id', AllColumns.* FROM (SELECT AnyColumnNameSuchAsDateColumn, ...etc FROM YourTableName WHERE YourCondition) AS AllColumns

Answer 3

This occurs when the tables primary key value, exceeds the range that MS Access supports, usually if you are using the "BigInt" type in SQL Server, if you are only looking to read the data then just create a "snap-shot" query for the table and all rows will display correctly as the "snap-shot" does not need to read all the indexes.

If you need to update the data in these rows at any time then I suggest using an ADO recordset instead.

Answer 4

If you set a primary key on a field where SQL is using the ROW_NUMBER() function you can cast it to int. By default ROW_NUMBER() is int64 (bigInt).