A new issue has cropped up this morning. I have databases that reside on SQL Server and I use Access for the front end. One of the databases which has been in use for at least 10 years now suddenly stopped working today, and I have found that the issue is one that is affecting 2 (possible more, I've not checked them all) tables.
When I open the table in access all I get is #DELETED in all the rows and colums. I have seen this behaviour before and it is usually something to do with the data type but this doesn't seem to be the case in this instance.
To troubleshoot the problem I have created a view that retrieves all the columns from the table and when this view is linked and opened in Access I have the same issue. I have found that if I link to the view without selecting a unique record identifier I can see the data without any problem. I could use this as a work-around, but clearly it is not ideal.
The SQL server version is 14.0.2037.2 and I am accessing it using SQL Server Native Client 11.0.
I have found the cause and solution. The affected tables had nvarchar fields as the primary keys. SQL Server Native Client has been deprecated for some time now and is replaced by MS OLE driver which is our mistake. The reason this problem has only reared its head now is due to an update to MS Access 365. I found this which has more details:
#DELETED when linked with ODBC
I had the same issue. This situation emerged this past weekend (5/29/2022).
This is a bug created by a 365 Office update. My update occurred 5/29/2022. The best remedy is to roll back your most-recent 365 update.
In my application, the #Deleted value appeared in all cells linked to any SQL Server table having a nvarchar field included in any unique index - it didn’t have to be a primary key. In my case, eliminating the unique attribute in any index including a nvarchar caused the problem to go away.
Related
A new issue has cropped up this morning. I have databases that reside on SQL Server and I use Access for the front end. One of the databases which has been in use for at least 10 years now suddenly stopped working today, and I have found that the issue is one that is affecting 2 (possible more, I've not checked them all) tables.
When I open the table in access all I get is #DELETED in all the rows and colums. I have seen this behaviour before and it is usually something to do with the data type but this doesn't seem to be the case in this instance.
To troubleshoot the problem I have created a view that retrieves all the columns from the table and when this view is linked and opened in Access I have the same issue. I have found that if I link to the view without selecting a unique record identifier I can see the data without any problem. I could use this as a work-around, but clearly it is not ideal.
The SQL server version is 14.0.2037.2 and I am accessing it using SQL Server Native Client 11.0.
I have found the cause and solution. The affected tables had nvarchar fields as the primary keys. SQL Server Native Client has been deprecated for some time now and is replaced by MS OLE driver which is our mistake. The reason this problem has only reared its head now is due to an update to MS Access 365. I found this which has more details:
#DELETED when linked with ODBC
I had the same issue. This situation emerged this past weekend (5/29/2022).
This is a bug created by a 365 Office update. My update occurred 5/29/2022. The best remedy is to roll back your most-recent 365 update.
In my application, the #Deleted value appeared in all cells linked to any SQL Server table having a nvarchar field included in any unique index - it didn’t have to be a primary key. In my case, eliminating the unique attribute in any index including a nvarchar caused the problem to go away.
I've a MS Access solution accessing to linked tables to SQL Server.
Today it happens that one key filed in a table reached the limit of int.
So my first idea was to change it from int -> bigint but it seems to be not possible as ALTER queries return a couple of errors for.
The second idea was to clone the key field, delete original and make the clone to the new key field.
This worked without problems but now the linked table only show #deleted values for all fields within the table.
It seems that MS Access uses the keys for some relations when it access to the backend.
Maybe somebody know a solution to extend /reset the key without loosing the relation for MS Access?
Thank you
MsAccess has a "long integer" number option in the table design, which has the same size of INT from SQL Server. See below:
https://www.microsoft.com/en-us/microsoft-365/blog/2017/03/06/new-in-access-2016-large-number-bigint-support/
I found this:
"Unfortunately, Access is unable to use BigInt as a primary key. You will most likely need to change this to a long integer. The article below is for an older version of Access, but the info still applies:" (https://answers.microsoft.com/en-us/msoffice/forum/all/linked-table-showing-deleted-in-all-rows-and/d0451a78-08c1-4667-8677-6c61edcebcf1)
So it seems not to be possible to use bigint as key.
I Googled this topic, and this is what I found...
Access CAN handle the BigInt datatype in SQL Server. Only, its handling of this is somewhat faulty.
As far as Access is concerned, BigInt is a STRING. You have to quote it as a string, within Access. Fortunately this isn't a problem on the SQL Server end, as SQL Server is happy with quoted numbers. In-between the two (Access and SQL Server), based on my experience, it appears there is a textual transmission of SQL commands from Access to SQL Server, with some modest dialect translation going on automatically in the background (if anyone knows better, please comment.) BigInt data coming from SQL Server to Access are automatically understood as strings.
https://social.msdn.microsoft.com/Forums/office/en-US/fb6f99ec-2ed7-487b-ba39-0777a0b44d5f/the-bigint-problem?forum=accessdev
MS Access is a 30 year old technology. Do you really want to be using that in 2022 and in the future?
I have a legacy Access 97 Frontend application which utilises a SQL Server 2005 backend over a SQL Server ODBC Driver (Connection), we use the Linked Table feature on this setup.
I create, amend and link in tables on a daily basis and I am aware of the conversions that occur between the different data types.
There seems to be an issue with one table that I recently created, it has exactly the same setup and permissions as many of the other tables in the database but once I link it into Access 97 it seems to show #NAME in all columns and I also receive an 'ODBC Call Failed' error.
If I remove the Primary Key from the table and do not select a 'Unique Record Identifier' then I am able to view the data in the table but I obviously can't edit it.
There are 3 columns which are VARCHAR's and are over 255, if I reduce these columns to 255 or less I am then able to view the data in the table but if I then try to edit or delete the data I receive a new error 'The Microsoft Jet Database engine stopped the process because you and another user are attempting to change the same data at the same time' - I know this is not possible because at present I am the only one with access to the table.
In this particular table there are 146 columns, if I delete half of these then the table starts to work as it should, again I have tables that have far more columns than this and work perfectly.
Troubleshooting issues like this can be frustrating for sure.
I have found this article very helpful for my linked tables:
Optimizing Microsoft Office Access Applications Linked to SQL Server
Specifically read the section titled Supporting Concurrency Checks.
One thing you might try is adding a "timestamp" column to the table in question.
We have an MS Access 2007 database with a MS SQL Server 2008 backend.
On the server, for each table, we have written a view, and each view contains triggers for update/insert/delete. These views are then linked into MS Access as linked tables.
Every server table contains a primary key consisting of one or more columns, plus a separate IDENTITY column (int, with unique index).
Now, if I go into MS Access and enter data directly into the linked table, everything works fine.
But if I create a Form, which uses the linked table as recordsource, then after each insert, all fields show #deleted. However, the data is stored correctly into the database, so it is mainly a display problem!
I think this has something to do with the triggers, but I cannot find the problem.
Can anyone help on this problem?
Problem solved. There was actually a problem in the trigger, which caused more than row to get updated or inserted. After fixing the trigger, everything works now.
I rencently used the SQL Server Migration Assistant to import a database into SQL Server 2005. I noticed that a number of tables that were imported have been ammended with a new column called SSMA_timestamp.
Can anyone tell me what this is for and how it would be used?
The added SSMA_timestamp columns are not only used during migration. They actually help avoid errors when Access updates records in tables linked to SQL Server. So if you are still using an Access front end linked to the migrated SQL Server database, it would be best to not drop the SSMA_timestamp columns.
From the MSDN article Optimizing Microsoft Office Access Applications Linked to SQL Server:
Supporting Concurrency Checks
Probably the leading cause of updatability problems in Office Access–linked tables is that Office Access is unable to verify whether data on the server matches what was last retrieved by the dynaset being updated. If Office Access cannot perform this verification, it assumes that the server row has been modified or deleted by another user and it aborts the update.
There are several types of data that Office Access is unable to check reliably for matching values. These include large object types, such as text, ntext, image, and the varchar(max), nvarchar(max), and varbinary(max) types introduced in SQL Server 2005. In addition, floating-point numeric types, such as real and float, are subject to rounding issues that can make comparisons imprecise, resulting in cancelled updates when the values haven't really changed. Office Access also has trouble updating tables containing bit columns that do not have a default value and that contain null values.
A quick and easy way to remedy these problems is to add a timestamp column to the table on SQL Server. The data in a timestamp column is completely unrelated to the date or time. Instead, it is a binary value that is guaranteed to be unique across the database and to increase automatically every time a new value is assigned to any column in the table. The ANSI standard term for this type of column is rowversion. This term is supported in SQL Server.
Office Access automatically detects when a table contains this type of column and uses it in the WHERE clause of all UPDATE and DELETE statements affecting that table. This is more efficient than verifying that all the other columns still have the same values they had when the dynaset was last refreshed.
The SQL Server Migration Assistant for Office Access automatically adds a column named SSMA_TimeStamp to any tables containing data types that could affect updatability.
I think this is generated so that the Migration assistant can detect changes to the data during the migration.
Unless you are continuing to use Access as a front end to this specific database you have migrated to SQL Server (in which case see Simon's answer), I don't think they will be used for anything after migration is complete, so it should be safe to drop these new columns once you are sure everything is done.
<!-- Set project preference.
Preference path/name/value can be found in preferences.prefs file stored in SSMA project directory.
Preference path is the node name path starting from root to leaf node separating by "/". -->
<set-project-preference preference-path="prefs/ssma-for-access/a2ss/conversion"
preference-name="timestamp-columns-opt"
preference-value="never" />
From SSMA GUI you can also click tools--> default project setting --> conversion --> Tables --> add timestamp columns --> set to Never