SQL table linked in MSAccess, insert yes, update/delete no

Zakraket

Registered User.
Local time
Today, 10:13
Joined
Feb 19, 2013
Messages
92
I have a fairly large ERP-system that I'm maintaining for a company. It's a MS Access front end with a SQL database. No issues so far.

Now I'm setting up a new table, like I have done numerous times in this system (and others), but now I'm running into this problem:

My new table allows inserts, but inserted records cannot be updated or deleted. That is, some records... I've never run into this before, and this table is nothing spectacular

1707988113197.png

The error (in dutch) states that the record has been changed by another user and therefore my changes cannot be applied (which is impossible since there are no other users on the developmentserver)

Even more strange: I cannot update or delete the first record, but I can alter the second record. This seems to be random.

I'm familiar with the following:
- a table needs a primary index key to function properly: this table has such a field
- SQL bit fields need to have a default (0 or 1) to prevent these warnings for MS Access boolean: this table does not have bitfields
- tabletriggers that write in the table after an update (through MSAccess) cause the table to be temporarily locked with the same error as above: no triggers on the table

Also
- I've recreated the table in various versions (omitting specific fields and options like constraints, but so far no luck)
- I've tried different drivers (SQL Server, ODBC Driver for SQL 17, SQL Server Native Client 11), all have the same issue
- every time I recreate the table I also create a new linked table, the tables are linked using a DSN-less connectionstring
Code:
ODBC;Driver={SQL Server Native Client 11.0};SERVER=XXXXXXXX\SBDEV;DATABASE=Dev20032;Trusted_Connection=Yes;APP=Microsoft Office 2010


I must be overlooking something very simple, but I cannot find it. Been into this issue for a day now and I'm getting really frustrated

This is my table, as you can see I've already omitted several options from the tabledefiniton, but the problem stays. Things like the auditfields (Created, Updated) are in all other tables the same way, no issues)

SQL:
IF OBJECT_ID(N'dbo.tblOrdOutputCfg', N'U') IS NOT NULL
   DROP TABLE [dbo].[tblOrdOutputCfg];
GO

CREATE TABLE [dbo].[tblOrdOutputCfg](
    [OrdOutputCfgID] [int] IDENTITY(1,1) NOT NULL,
    [OrdOutputCfgOrdID] [int] NOT NULL,
    [OrdOutputCfgOutPutNr] [int] NULL,
    [OrdOutputCfgQltyID] [int] NULL,
    [OrdOutputCfgSzID] [int] NULL,
    [OrdOutputCfgSilos] [nvarchar](255) NULL,
    --[OrdOutputCfgOutputGew] [decimal](10, 2) NULL,
    [OrdOutputCfgCreatedOn] [datetime] NULL,
    [OrdOutputCfgCreatedBy] [nvarchar](50) NULL,
    [OrdOutputCfgUpdatedOn] [datetime] NULL,
    [OrdOutputCfgUpdatedBy] [nvarchar](50) NULL,
CONSTRAINT [PK_tblOrdOutputCfg] PRIMARY KEY CLUSTERED
(
    [OrdOutputCfgID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[tblOrdOutputCfg] ADD  CONSTRAINT [DF_tblOrdOutputCfg_OrdOutputCfgCreatedOn]  DEFAULT (getdate()) FOR [OrdOutputCfgCreatedOn]
GO

--ALTER TABLE [dbo].[tblOrdOutputCfg] ADD  CONSTRAINT [DF_tblOrdOutputCfg_OrdOutputCfgCreatedBy]  DEFAULT ([dbo].[svfUsername]()) FOR [OrdOutputCfgCreatedBy]
--GO

--ALTER TABLE [dbo].[tblOrdOutputCfg]  WITH CHECK ADD  CONSTRAINT [FK_tblOrdOutputCfg_tblOrd] FOREIGN KEY([OrdOutputCfgOrdID])
--REFERENCES [dbo].[tblOrd] ([OrdID])
--ON DELETE CASCADE
--GO

--ALTER TABLE [dbo].[tblOrdOutputCfg] CHECK CONSTRAINT [FK_tblOrdOutputCfg_tblOrd]
--GO
 
Now I've narrowed it down to the constraint on the CreatedOn field (getdate())

When I leave the constraint out I do not have this issue. When I recreate the table without this constraint I can update all records. When I then add the constraint on the SQL-server (with an update to the table-def) and refresh the linked table, I cannot update (or delete) record 3 after inserting it

It's strange, since all tables have the same constraint on a CreatedOn field, like the other table below. I can enter a record and update it in the tblMaintType table.

What can be the reason this constraint does not work on one table and works on the other? Access inteprets them the same (2nd screenshot)

1707989152416.png


1707989455329.png
 
I have seen this problem and it's very frustrating.
Is it a DateTime(2) field in SQL?

If it does and you use GetDate() that now creates a default value that Access can't decipher as a valid date, and it basically makes the records un-editable.

If you go into the table in SQL server and enter a value in that field manually you will be able to edit that record.
Either change the data type to good old fashioned DateTime (Recommended by me) or Enable Date Time Extended support in the access front end. (I don't like this option it's flakey and Access still doesn't play well with this datatype).

1707991033116.png


Edit: I forgot a third option - make the default value supress the additional microseconds that the extended format allows for.
 
Thanks for your input.

It's Access version 1808 (9 jan 2024) but I don't have this specific option. But the field is a DateTime as you can see in the script, not datetime2. It's the same as in the other tables where I don't have the issue

Another example: I can edit the 3rd and 4th record but not the others, when the constraint on CreatedOn is in place. When I delete the constraint and refresh the link, the problem stays. Only when I set the CreatedOn for records 1,2,5,6 to NULL through SMSS I can edit the records in MS Access
1707992917167.png

It seems to me it has something to do with the datevalues, but I entered these records subsequently after each other, so they originally had timestamp with just a few seconds difference. This also matches with your option to alter the dates in SMSS to another value to "unlock" the records.

Ill see what happens when the records are locked, the constraint is active, and I edit the values to something different on SQL server (and create some records on SQL-server, maybe that makes a difference also)
 

Attachments

  • 1707993097135.png
    1707993097135.png
    20.4 KB · Views: 79
Last edited:
Re-reading your post a bit more accurately after a coffee or two, I'm sure it's a problem with the Getdate() function now returning more accuracy than it used to and Access not liking it. Truncating it to simply seconds seemed to fix the issue for a colleague. I seem to remember when I first came across it, I set the default value on the form, as a work around.

Currently my Azure SQL server is returning

SQL:
select GetDate()

2024-02-15 10:38:10.950

If I try and paste that into an access table date field I get an error.
If I remove the fractions of seconds I don't.

I suspect if you enable the extended Date Time support it might work?
 
Sorry for the double post.
If I add a datetime extended field to a test table after ticking the support option I can than enter that date:
1707993966868.png


1707993943500.png


I'm not happy with it though as I seem to remember you can't use a lot of the inbuilt VBA date functions with this new extended format.
Hence the work arounds...
 
I don't have the extended DateTime option (if you refer to the tickbox from your first sceenshot), so that's an issue

I could try what happens if I upgrade the GetDate() to enter a less precise date (using some other statement), but it's still a mistery to me why this works without problem in the other 100-ish tables in the system...

CONVERT(DATETIME, CONVERT(VARCHAR, GETDATE(), 120)) should return a datetime without the milliseconds

Why do you say "now returning more accurate"? Has this been changed very recently?
 
The table in SQL, some records updatebla, some not
1707996768558.png


When I UPDATE the date to not include milliseconds, I can update the other records through MS access

This is the other table: no records with milliseconds, except the one I added today

1707996928170.png


But the issue grows now, yet another (existing) table with old records; these records are also randomly not updatable, and all records contain milliseconds in their timestamp
1707997095589.png


Could there have been some update that causes this? My MS Access has been updated on 9- jan 2024, and MS has f*ckedup updates before... I have not been working on/with this table since before jan 9th (but it existed before that date without issues), so it could be this issue is caused by the latest MS Access update?
 
Looking a bit further; I know I never had issues to enter/update records in the table un untill a few weeks. My MSAccess build changed between 10th feb and 12th feb from build 10405 to 10406 and I am very sure that before this week this worked without issues.

So, faulty update from MS (again)

(*)I log Access versions/build when users log into the system since I discovered MS creates faulty MS Access updates
 
Last edited:
What is your SQL Server environment?
I'm afraid I don't know the answer to the why, but as you say something has definitely changed.

If you look at the entries in your older records, do they have the same level of precision in the Date Time fields in all records?
If they do then it is an error in the way Access is handling the date formats.
 
The table in SQL, some records updatebla, some not
View attachment 112567

When I UPDATE the date to not include milliseconds, I can update the other records through MS access

This is the other table: no records with milliseconds, except the one I added today

View attachment 112568

But the issue grows now, yet another (existing) table with old records; these records are also randomly not updatable, and all records contain milliseconds in their timestamp
View attachment 112569

Could there have been some update that causes this? My MS Access has been updated on 9- jan 2024, and MS has f*ckedup updates before... I have not been working on/with this table since before jan 9th (but it existed before that date without issues), so it could be this issue is caused by the latest MS Access update?
I don't have a specific answer, but I want to confirm that Extended Date/Time does introduce some problems not seen previously.

Look at the data type (using Design View) in the SQL Server table for MaintPlanCreatedOn. What is it in SQL Server?
 
@GPGeorge it's a normal DateTime field - as per the SQL table def in post #1

@Zakraket Okay I have done a little more digging.
On a table created years ago I added a new timestamp field about a year ago. This has a default constraint of GetDate()

Using version:
Microsoft® Access® for Microsoft 365 MSO (Version 2401 Build 16.0.17231.20194) 64-bit

I can see the field in access and edit that record. In Access:
1708000076999.png

In Sql:
1708000120335.png


So It might well be an Access version issue?
I can't work out what access version you are on from the build number.
 
@Minty. Thanks for reading the fine print for me. ;)

@Both. Which ODBC driver(s) are you using in this environment?
 
ODBC Driver - on the example I posted it's an old version! - DRIVER=SQL Server Native Client 11.0

I have just tried on a later version of the same database that we upgraded when we moved Servers a few months ago, and I am still able to edit successfully using - DRIVER=ODBC Driver 18 for SQL Server;
 
ODBC Driver - on the example I posted it's an old version! - DRIVER=SQL Server Native Client 11.0

I have just tried on a later version of the same database that we upgraded when we moved Servers a few months ago, and I am still able to edit successfully using - DRIVER=ODBC Driver 18 for SQL Server;
I would expect the newer drivers to handle DateTime datatypes better than older drivers.
 
I've tried ODBC Driver 17 and 18 for SQL server but that doesn't make a difference, the issue also seems to be in every table that has a field that defaults to GetDate()

SQL server is 2019

The version of MS Access is 16.0.10406 32bit, and up untill this weekend (serverpark restart by IT due to updates) I was on 16.0.10405. The problem occured yesterday, which was the first time I worked on the database since the update to this build. The update was installed somewhere between last saturdayevening and mondayevening (the userlog I keep shows this)

So it might be that a different driver works better, but still it seems to me MS changed something in this build that now causes this. Up untill last friday I never encountered any issues.

I linked a copy of client on my own laptop to the SQL server (VPN), and on my Access Version 64bit 2308 build 16731.20504 (sep 2023) I have the same problem; however I do have the tickbox for datetime2 in my options and when I enable this the problem is gone.
I don't have this option in the clients environment as stated. Assuming it might be a MS Access 64bit option

Using this as default also fixes the issue: CONVERT(DATETIME, CONVERT(VARCHAR, GETDATE(), 120)). Of course that's a workaround and I'm not going to update every table in the system to get it working.

Anyway, this issue is related to date columns (and specifically dates with milliseconds), and is MS Access related. I strongly suspect MS to have changed something in this update.
I contacted IT to see if they can degrade MS Access back to build 10405 from before last saturday, but they have not been able to do so.

For now I can work without a GetDate() on the column, since I'm developing new functionality, but I will run into problems when I want to edit records in existing tables. See what MS has to say on google in the meantime...

edit: another solution would be to use smalldatetime I suppose; that doesn't register milliseconds. It would also be easier to convert all existing tables to smalldatetime for these fields with a single script than since all milliseconds would be cut off with a field update.
 
Last edited:
The error (in dutch) states that the record has been changed by another user and therefore my changes cannot be applied (which is impossible since there are no other users on the developmentserver)
Make sure that you are not conflicting with yourself. This looks (in format) like the message you get from Access. If you are using a bound form and you update the data from outside the form, you will be conflicting with yourself. No other user needs to be logged in. For example, you have main form A which is updateable but shows a list of items. You also have a popup form that lets you edit the data in more detail. If you modify the record on form A but do not save it, open form B and modify the record in form B - you will get this error message. The simple solution in this case is to always save the current record before opening another form or report that references it. There are other situations where you conflict with yourself so, maybe walk through the code to see if you can find where it is happening.
I could try what happens if I upgrade the GetDate()
I use GetDate() as the default in my SQL Server tables. I have no problem with DateTime data type fields.
 
I know it works that way, but I'm only working in the newly created table so far, there are no forms in the picture thusfar (as the screenshots show)

Getdate() has worked for me to without issues up untill yesterday, on several databases with different clients in the last 10-12 years....
 
@Pat Hartman - This is definitely a issue, I've seen it myself, I just can't replicate it at the moment.

The SmallDateTIme is another option I forgot about, and I believe I may have also used as a workaround that where the time accuracy wasn't critical.

Which ever way you look at it it's a bug.
 
Maybe this thread will help to nail down when the bug happens then.
 

Users who are viewing this thread

Back
Top Bottom