Right now, the session number is only found from the local database file. But if you run a subject in another rig, the session number should still increment. A possibility is that looks in the remote directory at all databases, finds the highest session number, and then chooses that.
Here's an idea of how to fix this:
"on line 740 writeExperimentSessionToDatabase is called. in that function it would be possible to do it. Basically a loop on line 8 should find you both the most recent session number and the db it came from (you’d use a param pointing to the server with all the databases stored to find and open each db, except for this rig’s db for which you’d use the open one passed in as sqlDb). Then lines 10-29 will use that db (with the most recent session, probably sqlDb) to find all the info sessions. Then that can get closed (if it’s not this rig’s db) and sqlDb would be used for the rest of the code."
Right now, the session number is only found from the local database file. But if you run a subject in another rig, the session number should still increment. A possibility is that looks in the remote directory at all databases, finds the highest session number, and then chooses that.
Here's an idea of how to fix this: "on line 740 writeExperimentSessionToDatabase is called. in that function it would be possible to do it. Basically a loop on line 8 should find you both the most recent session number and the db it came from (you’d use a param pointing to the server with all the databases stored to find and open each db, except for this rig’s db for which you’d use the open one passed in as sqlDb). Then lines 10-29 will use that db (with the most recent session, probably sqlDb) to find all the info sessions. Then that can get closed (if it’s not this rig’s db) and sqlDb would be used for the rest of the code."