From Bcontrol

There are four functions supported by the sqlsummary plugin:


getSessID returns the session id that is the unique id that identifies the current session in the mysql server. If no session id exists it gets one.

function x=getSessID(obj)
if ~exist('sessid','var')
if value(sessid)==-1
   bdata('insert into sess_list () values ()');
   x=bdata('select last_insert_id()');



will send a summary of your session to a mysql server.

 function [err]=sendsummary(obj, varargin)
 pairs = { ...
 		'hits'			get_val('hit_history');...
 		'sides'			get_val('previous_sides');...
 		'endtime'		datestr(now,13);...
 		'sessiondate'		datestr(now,29);...
 		'hostname'		get_val('SavingSection_hostname');...
 		'experimenter'		get_val('SavingSection_experimenter');...
 		'ratname'		get_val('SavingSection_ratname');...
 		'n_done_trials'		get_val('n_done_trials');...
 		'protocol'		class(obj);...
 		'protocol_data'		'NULL'
 		}; parseargs(varargin, pairs);
 %% Get the relevant SPH

With no extra arguments sendsummary tries to generate a summary making the following assumptions:

  1. There is a SoloParamHandle named hit_history that contains a numeric array containing a 1 for every correct trial, a 0 for incorrect trials and NaN for trials that should not be treated as correct or incorrect.
  2. There is a SoloParamHandle named previous_sides that contains a string of l's and r's to indicate whether the correct response was towards the left or the right.
  3. That the @saveload plugin is being used.

You can still use this function if the above assumptions are false. In this case, pass in the appropriate information as parameters.

For example, you don't have an SPH called previous_sides but rather you store this information in sides_history and it is made up of -1's and 1's. In this case, write a little bit of code to transform your sides_history into a string of l's and r's and then send the string as an argument to sendsummary.

 lets={'l' 'c' 'r'};
 sendsummary(obj, 'sides',sides)

The other feature worth noting is the protocol_data field. You can build any struct or cell array you like and pass it in. For example:


The advantage of this is that you can then write code that grabs the protocol_data for a specific set of sessions and runs through some analysis without having to load the entire data file for each session. This could significantly simplify analysis of behavior and replace hunt. The only constraint is that you cannot use sparse matrices in this field. This is a limitation of mym.

NOTE: Currently this functionality is only supported for the Brody Lab. Users outside of the brody lab must set up a mysql server for their lab and replace the bdata.p file found in ExperPort/MySQLUtility using bdata_template.m.

Jerlich 20:23, 29 December 2007 (EST)


The sendtrial function can only take a single input - the protocol object.

 % [] = sendtrial(obj)
 % Pushes the scalar soloparamhandles for all trials to a table with the protocol name
 % ----------
 % obj     This is the protocol object

This function would normally be called in the pre_saving_settings section of your protocol. That way after the behavioral session is done and the data has been saved to disk, then this function sends data to the mysql server.

In order for this function to work a table with the protocol name needs to be created in the protocol schema on the mysql server.

An example script for building such a table can be viewed in ExperPort/Analysis/ExtendedStimulus/build_es_table.m

After building the table, one should go through the table by hand using the mysql query browser and eliminate columns that are clearly not of interest or of incompatible type.


The push_helper_vars_tosql function takes two inputs - the protocol object and n_done_trials.

This function should be called in the prepare_next_trial section of your protocol after updating n_done_trials but before evaluating the training string in SessionDefinition (which recomputes the helper vars for the next trial). It gets all the helper vars and their values for the previous (just completed) trial, and for the ones whose "save_to_helper_vars_table" user property is 1, sends them to the protocol.helper_vars tables in the SQL database.