Great question. Here is what the settings are for the survey.

Anonymized responses:
Responses to this survey are NOT anonymized. Cannot be changed
Enable token-based response persistence: Off
Allow multiple responses or update responses with one token: Off
Allow public registration: Off
Use HTML format for token emails: On
Send confirmation emails: On

This may cause my issue, I will test. If you have any more information on how the reaction with these settings, I welcome it.

Thank you.

Well, if your problem is that whenever you use the same token a new survey is started, then yes, enabling the token based response persistence should solve the problem.

If there is any other problem that you are still phasing, please explain.

I create a new survey. Just a generic one question survey to test all of the connectivity and installation is correct. I am not using tokens at this time because the majority of the surveys are taken anonymously and can be taken many times by the same person. I activate the survey I create and copy the link. I paste the link into a new Chrome browser and receive the message "Did not save" at the top of the Welcome page. I select save page as HTML and the message does not appear in the HTML file. The initial load of the page does create a record in the database.
Next, I decide to ignore the message since it does not appear in the HTML save file. I receive the same "Did not save" on the displayed survey. Another record is created in the database, did not update the record from the welcome page load.

This is why I have so many records in the database because it creates a new one each page that it loads like below.
id token submitdate lastpage startlanguage seed 922767X1X1SQ001 922767X1X1SQ002 922767X1X1SQ003 922767X1X2SQ001 922767X1X2SQ002 922767X1X2SQ003
1 NULL NULL NULL en 563747071 NULL NULL NULL NULL NULL NULL
2 NULL NULL NULL en 563747071 NULL NULL NULL NULL NULL NULL
3 NULL NULL NULL en 563747071 NULL NULL NULL NULL NULL NULL
4 NULL NULL NULL en 563747071 NULL NULL NULL NULL NULL NULL
5 NULL NULL NULL en 334104734 NULL NULL NULL NULL NULL NULL
6 NULL NULL NULL en 334104734 NULL NULL NULL NULL NULL NULL
7 NULL NULL NULL en 334104734 NULL NULL NULL NULL NULL NULL

OK, no token. Understood.

First of all: If you don't use tokens, each time you open the survey link a new line will be created. This is generally normal behavior.

However, you should not have the problem with "did not save". This is strange.

That is what I would expect since I currently have 1.87 working in production. We need to update and I have been having this failure for over a month.

My guess would be that it has something to do with your server generation, because I haven't seen your error here in the forum so far. Only you both and in both cases it is MS SQL.
Limesurvey is being developed generally in LAMP enviroments and tests on MS based servers is generally very limited. I think the biggest user base also uses LAMP, so it could be a MS specific bug as well. But with what we have at the moment, it is difficult to reproduce.

Your installations of 3.x are clean installations from scratch?

What sometimes happens is that there are problems with the database driver. But for you, during installation the option MS SQL must have been shown to even be able to install it. So I guess LS recognizes the database, so it shouldn't really be a driver problem either.

I have done many clean installs, just easier than updating. Our 1.87 works on Server 2008 R2 with MSSQL 2008, both go out of support 2020. I have done a clean install with Apache 2.4 and PHP 7.0 as well. It has the exact same issue. This told me the issue had to be with the MSSQL. I had the DBAs create a 2012 version, before Azure became the plumbing. Still the same issue.

My assumption is there is a session setting that keeps the database connection open. I believe this is not being kept open or the session values are being lost. I just can't find the documentation so I can prove or disprove my assumption.

I am a little bit out of options. I am not really a server specialist either. The only chance that I currently see is to create a bug report for this and see if the developers can reproduce.

You have been great in attempting to help. Hopefully you are watching for this question.

I see the database communication should be using session variables that are stored in a file. I cannot see the files being created. Is there some configuration for this communication? I really believe this is not being done correctly so it can keep the connection open.

My wording may be incorrect because I am used to C# and VB programming.

I just found more information. Admin is able to see each attempt to load, for instance right now I have 11 Partial surveys out a total of 11. This is from 4 checks. I added more information on PHP for MSSQL and it caused the connection to the database to fail.

I have checked session variables and the session files are being saved and have the complete survey in it. Therefore, it is a connection between LimeSurvey and PHP that is failing to keep the connection open to the database. I just need to get around this.

Any thoughts?