I am currently working on moving to 2012 SQL Server which is v11, v12 is where Azure became the standard. Our old installation is with 2008 SQL Server. I can see some differences in MSSMS so I am hoping this will solve my problem. I will post my results so others may learn from my issue.

I finally was able to test with 2012 SQL Server. I am still having the same issue with limesurvey3.7.2+180508.zip with both Apache and IIS. (Yes, I have installed both separately to eliminate any of the issues.)

Here is what the DB table looks like once I attempt to take the survey.

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

Basically, each time the survey loads it writes a record to the table. It is unable to update the record it wrote.

There has to be a setting missing or some configuration LimeSurvey support takes for granted but the rest of us do not know about.

Well, depending on your settings, Limesurvey either creates a new line in the data base (token based response persistence OFF) or updates the previous entry (response persistence ON). Or did I understand your new problem wrong?

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.