BackEnd getting corrupted since (I think) Win 10 updates (1 Viewer)

[bignose2]

It WAS the 1803 update causing all the problems.

I had earlier rolled back one separate laptop & thought I had tested and continued to get the corruption but obviously not tested enough. I think I had convinced myself it was not this as the update was on the 16th & I only started getting problems on the 19th so perhaps did not test as much as I should but I did have some 1803's still on the network & perhaps it was this.

Anyway restored all 4 PC & done lost of tests and really sure it is OK now.

So as a very considerable amount of people have found 1803 causes a very wide range of issue & mine was really, really specific.

I had done a recent Windows update that was after the main 1803 & that had not helped either so want to stick with 1709 for a good few months.

Just noticed on Pro you can defer auto updates.

 

[isladogs]

Interesting....!
Perhaps you should have trusted your hunch earlier
Do report it as a bug via the feedback hub

So now to find a way to stop this update but keep other security & important stuff, seems hard now on Windows 10, you can't pick & choose but too investigate now.

I had done a recent Windows update that was after the main 1803 & that had not helped either so want to stick with 1709 for a good few months.

I also tested the 1803 cumulative update unsuccessfully for my issue.
Having removed 1803 from 3 PCs, I now have all 3 PCs trying to revert back to 1803 - I'm deferring repeatedly but haven't found a way of saying NO - STOP IT. If you do so, I'd like to know

 

[bignose2]

Not tried yet but hopefully below will work..

https://www.computerworld.com/artic...april-2018-update-from-installing.html?page=2

Wushowhide - Is official MS stuff
Meant to hide upgrades, I have not got the upgrade message back yet so would be interested.

I am not sure if this will auto upgrade & not get the chance to use this.
Also being a major upgrade perhaps not block.

The metered connection trick also looks interesting but I would prefer above.

I do have one Windows 10 Pro PC & that has simple option to defer Feature updates or security. How can this be just a Pro option?!?!

So stupid because lots of people may simply turn off the updates service & miss security updates - which MS are meant to be so conscious about now!

Anyway would be interested how the 1803 is offered or forced, I can't remember now. I am going away soon & can't leave my staff to roll back!

 

[Gasman]

Colin,

We had an update in work, that mucked up the indexing for Outlook.
It had not happened on my laptop at that time, so I put this cmd file in the task scheduler to run every hour, as windows seemed to switch it on sometimes.

This disabled the windows update as the outlook indexing was more important to me.

The 1803 or some subsequent update has seemed to fix the problem and the pst files are now back in outlook search options.

Rem stop windows update
sc config "wuauserv" start= disabled
sc stop "wuauserv"
rem Pause

HTH

So why not test whether the 1803 update is the issue.
Restore version 1709. It only takes a few minutes
You have up to 10 days to restore the previous build (1709) before it is automatically deleted

I've just done so again on my tablet - my problem solved ... for now ... till auto update kicks in again

 

[isladogs]

Gasman / bignose2

thanks both - I will try one (or more if necessary) of these suggestions.
As I had already installed 1803 on 3 PCs (unintentionally on 2 of them), the files are sitting ready to install ...as it keeps tells me
There's only one way to tell whether they will work in that scenario

 

[static]

Quite a lot of memo fields, would take some counting, is a large database.

Not going to solve your problem but this is all I needed to hear.
The fact you haven't had issues before is amazing.
Anything that could impact your network performance could tip your Access database over the edge if it has even one memo field.

 

[isladogs]

@static
Do you have any EVIDENCE to justify your assertion?

Here's a link that does support your comments about memo fields being susceptible to corruption:
https://bytes.com/topic/access/insights/947191-risks-involved-when-using-memo-fields-ms-access-databases
Its largely based on articles by Allen Browne - links included

Having said that, I have for many years used memo fields where appropriate for various reasons:
a) where extended text is needed > 255 characters e.g. importing some files from external sources such as some JSON files
b) to allow rich text formatting of the text

I'm well aware of issues related to truncation of memo fields in certain situations but that's not the point here.

In almost 20 years, I've experienced less than 10 instances of corruption in Access data & only a small proportion of those were in memo fields. So, personally, I am not convinced by these arguments. As such, I agree with the response to the article by a well respected developer, Anders Ebro (Smiley Coder)

 

[static]

Memo fields have never been safe to use. I don't need to provide evidence because it's always been common knowledge and the post you linked doesn't argue otherwise.

 

[isladogs]

Memo fields have never been safe to use. I don't need to provide evidence because it's always been common knowledge and the post you linked doesn't argue otherwise.

Just making assertions without evidence isn't enough.
I deliberately provided a link to support your view as you hadn't done so.
However, if you read the entire link it contains replies which strongly disagree.

Back in the days of Access 97, MS apparently made changes which dealt with memo field issues

As I said, I have used memo fields WHERE APPROPRIATE for many years without any issues so have no first hand knowledge to back up your comment. In fact the opposite.

That may be because my memo fields are rarely edited - their contents tend to be 'static' (sorry about the pun)
Whatever the reason, my experience is that memo fields, used wisely, are no more risky than other datatypes.

So once again I say, do you have any real evidence or can you provide informed references to back up your comments.

 

[static]

I've read that thread twice and don't see any disagreement at all.

 

[isladogs]

I've read that thread twice and don't see any disagreement at all.

Try reading the replies by smiley coder etc. Very clear disagreement.
I also found other links both to support and refute this viewpoint.

I'd have been perfectly happy if you had made a comment about using memo fields with caution and to place them in a separate table if these are likely to be edited frequently in a multi user environment.
But that's totally different from stating that 'even one memo field could tip your database over the edge' in terms of corruption

 

[static]

If the OP had been here to discuss database design I probably would have written something like that.
But he wasn't so I didn't.

I have no idea who 'smiley coder' is. Probably you.
"I haven't seen any empirical evidence IN MY OWN work as of yet." isn't "Very clear disagreement."

I also clearly linked memo field corruption to network problems.

Of course, network issues could affect any database. Access more than others. And any field. Memo fields more than others.

 

[isladogs]

I have no idea who 'smiley coder' is. Probably you.

Don't be silly. I told you who he was in the first reply. Ambers Ebro has a very useful Access website: See: http://thesmileycoder.com/

His comment "I haven't seen any empirical evidence IN MY OWN work as of yet." is stating his (in my view) expert opinion based on many years experience. He is also wise enough to qualify his statement rather than make blanket assertions based on a lack of evidence.

I still haven't seen any evidence based on actual experience in your replies.

Of course, network issues could affect any database. Access more than others. And any field. Memo fields more than others.

Hmm...here we go again.
The first and third sentences are definitely true.
The second sentence depends on what you are comparing Access with.
The last sentence is the same point as before but at least this time you're not saying 'one memo field could tip your database over the edge in terms of corruption'

 

[static]

I get the feeling you're just being a troll so I'll leave you alone.

Let's hope the Windows update gets sorted.

 

[isladogs]

I get the feeling you're just being a troll so I'll leave you alone.

Wrong again.
But a better answer is

do you have any EVIDENCE to justify your assertion?

See post 27

 

[RogerCooper]

You probably already tried this, but I had a similar problem 2 weeks ago, which I resolved by updating Access 2016 on the work stations where the errors occurred.

 

[Mark_]

@ OP,

From a network design standpoint, storing your data on a users machine is not nearly as efficient as having it reside on a dedicated file server of some type. As you may have noticed workstations are not set up for balanced resource sharing. While it may work and be stable at times, as soon as the users starts doing anything resource intensive you can run into issues.

I do think you will find your NAS to be a much better option long term. I'd also make sure it has a very stable connection to your network, giving it priority over other machines.

 

[Pyro]

Hi,

It has been a while, but i wanted to weigh in on this. I have had several databases come up with the same issue over the past couple of weeks. After many headaches, and much researching, it appears that this error may be linked with the 1803 update. MS seem to have acknowledged it (see link below). A work around can be found here.

 

[TheHamster]

Hi. I just joined to add a comment.

We have had this problem for a few days. We thought it was genuine corruption, but we came to the conclusion independently that it may have been the W10 Update, and we also think it might have been fixed by a later update KB4284835. Does anyone have any information on this?

We managed to locate this thread, although reports on the W10 update did not mention Access in particular.

Our access backend is linked to by access front ends, and non-access front ends.

One other thing. We noticed the backend ldb file grew in size. I suspect it may have reached 16K and that caused the crash. Post 38 includes a link, which discusses a couple of work rounds, one of which is the registry entry for "leasing". I didn't understand this title, but I now think it may refer to negotiating a connection with the backend.

Now with regard to this, we noticed a lot of blank areas in the back end ldb file. In order to see clearly, I copied the ldb file to a text file, and then opened it in notepad, and replaced spaces with periods. I could then slice each row of the ldb file into 64 byte chunks many of which were blank. My ldb file grew to 6K, and had about 90 entries. At one point I am sure I saw it grow instantly to 16K, but I missed the significance of this at the time, and didn't copy it. Note that the ldb file very occasionally had entries that were not 64 bytes when viewed as spaces (normally 63 bytes), but became 64 bytes with the search and replace. I didn't check with a hex viewer, but I wondered whether a chr(0), say would be replaced by a space. It's easy to see because a notepad line of 1024 characters has 16 logins each of 64 bytes. A full 16K ldb file will have 16 lines of data.

Anyway based on this, I wonder (conjecture only) if the W10 error (perhaps to do with the leasing flag) causes a client PC attempting to connect to the backend to sometimes need multiple attempts to connect to the backend, each time writing a blank 64-char sector into the ldb file. When it reaches 16K, (255 users) Access then crashes. Does anyone have any thoughts on this please? Could anyone with this issue check their ldb files to see if they have blank entries as well?

As part of this, I came to the conclusion that when a user logs off a database his "slot" in the ldb file becomes available for reuse, and will get overwritten by a new user, but always remains visible once used. Thus an ldb file seems to be able to grow bigger but not smaller.

 

[isladogs]

Hello and welcome to AWF.
If you haven't already done so, I suggest you keep an eye on this thread at the DevHut website: https://www.access-programmers.co.uk/forums/showthread.php?t=299829 which I mentioned earlier today in this parallel thread: https://www.access-programmers.co.uk/forums/showthread.php?t=300172

I personally haven't experienced this issue as I removed the v1803 update from all three of my PCs. I reverted to 1709 once I realised 1803 update was responsible for stopping the geolocation service in IE that I was using in one of my apps.
See this link for details https://www.access-programmers.co.uk/forums/showthread.php?t=299932
That issue has also been agreed to be a bug by MS for action (at some point).

All in all, Win 1803 has been the most buggy update I've known since the initial version of Access 2003 SP3 (before the hotfix).
Anyone else remember that?