It would be good to know if the commit fixes the issue, but I feel like it’s accomplishing something similar to turning audit logging off in by making the system ignore the $GLOBALS=$lastid call in log.inc in auditSQLEvent.
I would like to know that underlying pathology and not just treat the symptom.
Related code in sql.inc
// Function that will safely return the last
// ID inserted, and accounts for
// the audit engine.
function getSqlLastID() {
if ($GLOBALS['lastidado'] >0) {
return $GLOBALS['lastidado'];
}
else {
return $GLOBALS['adodb']['db']->Insert_ID();
}
}
I was able to test the two file updates (library\adodb\adodb.inc.php and library\sql.inc from github) and it seems to work. I have “Enable Audit” on and when I create a new visit for a patient, the reason and provider show up as they should. I checked the db and the form_id in the forms table gets set correctly. I haven’t done any deeper testing to see if anything else was affected, but the problem at hand looks resolved.
Just an update on my previous posts I changed my setup to use XAMPP 1.7.3 and the behavior with the Encounter forms and other clinical forms no longer occurs. When I try to view a past Encounter under the new set-up everything works fine. Even added some of the forms from the contrib folder to double check and everything is as it should be. Guess OpenEMR has some problems with Windows 7 set-up with Apache and PHP
Kevin,
I completely agree with you. There have been several fixes to this (where the audit engine breaks the the increment id stuff in mysql) by Visolve (whom did a good analyis before each fix); I’ll try to dig up their fixes and documentation of them.
guanacolibre,
Just wanted to confirm that this fixed the issue on XAMPP 1.7.4 and higher.
I have had this problem twice: first solution was mysql > flush privileges; second solution was a downgrade of php from 5.3.8 to 5.2.17. We use OpenEMR 4.1.0 (2), linux, apache, php, mysql - not xampp.
The “form_id in the form table gets a strange value” - In my case the value was 6 digits instead of our normal 4 digits and the values seem to increment randomly. By carefully matching the values in forms and form_encounter tables, I was able to restore access to the encounters.
In the encounter history frame (left nav | Patient | Visits | Visit history ), there is this javascript function:
//function toencounter(enc, datestr) {
function toencounter(rawdata) {
var parts = rawdata.split("~");
var enc = parts[0];
var datestr = parts[1];
top.restoreSession();
parent.left_nav.setEncounter(datestr, enc, window.name);
parent.left_nav.setRadio(window.name, 'enc');
parent.left_nav.loadFrame('enc2', window.name, 'patient_file/encounter/encounter_top.php?set_encounter=' + enc);
}
I am not suggesting any error in the javascript function, but I believe the “rawdata” argument is not properly formed so the encounter is not found in the tables and there is no data for correctly rendering the encounter summary. I think the 1969-12-31 date might be the result from date(0). I tried to trace things for a while, but did not have time. Perhaps the source of the “rawdata” for the javascript function will lead to the underlying problem.
What is confusing about this bug is that it is so dependent on php version.
Here is another snippet of code that seems related
I thinking about this, I’m not sure that the ViSolve added coded at the end of this function actually makes sense to include.
My understanding is that purpose of $GLOBALS you have a way to access the mysql_insert_id when logging is turned on. Otherwise, mysql_insert_id() will return the value of last id added to the log table, instead of the id of the table you are actually manipulating (forms, form_encounter).
But, when calling GenID, you are after the next a value in a sequence. (different from the ID.)
function GenID($seqname='adodbseq',$startID=1)
{
// post-nuke sets hasGenID to false
if (!$this->hasGenID) return false;
$savelog = $this->_logsql;
$this->_logsql = false;
$getnext = sprintf($this->_genIDSQL,$seqname);
$holdtransOK = $this->_transOK; // save the current status
$rs = @$this->Execute($getnext);
if (!$rs) {
if ($holdtransOK) $this->_transOK = true; //if the status was ok before reset
$u = strtoupper($seqname);
$this->Execute(sprintf($this->_genSeqSQL,$seqname));
$this->Execute(sprintf($this->_genSeq2SQL,$seqname,$startID-1));
$rs = $this->Execute($getnext);
}
$this->genID = mysql_insert_id($this->_connectionID);
if ($rs) $rs->Close();
$this->_logsql = $savelog;
// ViSolve : Sep 24,2010
// Instead of returning the generated LAST_INSERT_ID, the manipulated value
// from the $GLOBALS['lastidado'] is returned.
if($GLOBALS['lastidado'])
return $GLOBALS['lastidado'];
else
return $this->genID;
}
So part of what is going on is that form_encounters (and other tables as well) have TWO distinct ids. There is the column named 'ID" which is generated by mysql through autoincrement, and there is encounter which is generated by _genIDSQL.
It’s possible that the different versions of php don’t work correctly with _genIDSQL.