Thanks for this additional information. That sounds really interesting.

A few follow up questions if you don't mind:

1. How (technically) do you detect if an Internet connection is available?

2. Do you use a daily cronjob to import the uploaded VV files?

3. I still don't really understadn how you make sure that e.g. data set "A" (completed yesterday) doesn't get uploaded again at todays upload.
Do you only upload those data sets being edited the current day?

4. Does updating samples mean that they load a list of new participants from the server, like a CSV file of new token data?

Thanks for sharing your approach.

I'd love to share information and am open to all the opinion and advices.
1.Try to open a web page file, such as www.google.com , using fopen( ) function. If we can open the file, then the internet is connected, otherwise, no connection.

2.I really appreciate you mentioned the cron job! For now, we've only completed the functions to meet the basic needs. The supervisors will have to import the vv files manually. Of course we rewrite the dataentry.php file so that they can import many vv files just like importing one. We have already planned to automaticly import vv files using shell in the next version.

3.We can't just upload the current day's surveys because we can't be sure that the interviewers can upload their surveys everyday, although the off-line end will pop up an alert when the interviewers haven't done the uploading operation in the last 24 hours.
So here's our solution: we modify the lime_survey_(sid) table by adding some useful columns, one of which is to record whether the certain row needs to be uploaded in the next uploading operation. Let's name the column A. A is either 0 or 1. 0 is the default value, meaning this row of data needs to be uploaded. 1 means that the row has already been uploaded in completion and doesn't need to be uploaded any more. Now you can tell, the newly inserted surveys, the uncompleted surveys and the not-yet-uploaded completed surveys are all set to 0. Only the ones that are completed and just uploaded will be set to 1, so in the next uploading the row wouldn't be uploaded again because we only upload those with A being 0.

4. We update the token table in the off-line end. Our survey is not anonymous and has a token table. The supervisors manage the token table on the server end. They generate a .sql file from the token table and upload the file to the ftp server when there are samples to be updated on the off-line ends. The interviewers will just click the update button and the .sql file will be downloaded to their systems to update their token tables backstage.

We are doing this for our own needs. I'd really like to know what kind of off-line limesurvey do you expect if you don't mind.

Again, thanks for your feedback.

@1: That's the approach I had in mind as well.

@2: For projects like this I use cronjobs a lot. It really helps to automatize stuff like such daily jobs.

@3: That additional column for noting the upload status makes sense. Did you think about using an additional table instead? Adding columns to the main "lime_survey_12345" table may break other features.
All you need when using a new, separate table is SID + Data set ID + status column.

@4. Do you create a single file for each interviewer?

@"I'd really like to know what kind of off-line limesurvey do you expect if you don't mind.": Sure: Our company deals with ~100 survey projects for dozens of customers each year. Some of them have similar requirements:
- doing surveys offline
- uploading data if Internet connection is available
- keeping data in sync

Most of them decided to not spend any additional money on coding such features you mentioned. Instead, they do all that uploading and data export/import stuff manually.
As an IT guy, I really hate seeing this because I know that when spending just a little time (and money), such a process can be automatized nicely, as you have proven.

If you are interested in more details, you can drop me a note at marcel.minke(at)limesurvey.org

Did you ever find a solution to this?

We are dealing with the exact same error. Exporting only part of the results works fine, but exporting all 10.000 responses result in the error you describe. Nothing in error logs and no special configuration. PHP.ini is already optimized to deal with larger data.

PHP.ini is already optimized to deal with larger data.

Probably not, if you are getting the error when exporting all 10.000, but having no problem with a smaller sample.

And you have two aspects here: "large data" AND "long execution of scripts". Did you have a look into the limit for the execution time for scripts? Because the script to create the data file might run into limits there.