I’ve discovered a strange error that may somehow be related to my local configuration, but it’s got me stumped. It didn’t appear in 4.0 running on Ubuntu, but for 4.0/4.1 on Windows (wamp) and 4.1 on Ubuntu the internal form_id gets a strange value when I create a new visit and type in the brief description. This description shows up on the visit history listing, but when I view the encounter info it doesn’t show up under “Patient Encounter” where it’s supposed to. Previously it always showed up (showing the Reason and Provider), but on this new installation it looks like the form_id in the form table gets a strange value. When I go into phpmyadmin and set this value manually, everything works as expected. Where is this number set, and why would it not be inserted correctly? When I import the database from the 4.0 Ubuntu installation (where everything worked fine), already existing encounters work correctly (since they have a correct form_id) but when I create a new visit the form_id gets an incorrect value. We are hoping to do an installation on a Windows network, so just running it on Ubuntu is unfortunately not an issue. And even then it seems like this problem is happening on a new 4.1 installation on Ubuntu as well.
Any ideas?
One other possibly related issue is that the language suddenly changes, sometimes, going from Spanish to German, or even a mix of languages. On the same form there will be bits of 2-3 languages where previous it was all in Spanish. Do I possibly have some configuration incorrect on my computer, or wamp?
We had faced similar issue, but not in xamp.There is in instruction in PHP windows version down load page that, PHP VC6 binary should be used along with apache 2 versions. We were using VC9 versions of PHP and was creating this issue. I don’t know what is the combination using in xamp, and whether this is the cause of issue.
Ahoy Guanacolibre,
If you are running openemr on an ubuntu server (LAMP stack), it shouldn’t matter what are the OS’s of the other computers on the network. That is, the Windows boxes on the network should browse to the openemr web page without difficulty. Am I missing something? Did you mean you are only able to use a Windows server for this installation? Can you run VMWare or VirtualBox on the Windows server, then use the ubuntu appliance?
Jack
The installation is running on a standalone windows 7 laptop with apache v2.2.17, php v5.3.4. mysql v5.1.53. For now we’re not on a network but may use an Ubuntu server down the road. It looks to be php VC9 (where do I check that?) from what I see in the php.ini, but it was the version of php that came with wamp.
The form_id numbers went from one or two digit (12, 13, 14) to three or four digit (291, 300, 1509, 1622, etc) but only for form_name= “New Patient Encounter” as far as I can tell. It doesn’t look exponential, just too many digits, and sort of random what gets put in or only one of the digits corresponding. If I manually go and change the form_id to in the form table to match the id in the form_encounter table it works. Somehow it’s not holding/setting the proper value for some variable (?), and after I click save it shows me the blank Encounter form instead of the info I just entered. It does however list everything correctly in the Visit History listing.
I had VC9 running, so downloaded the xampp version with VC6. It didn’t seem to make a difference.
On a fresh install of 4.1 running xampp-win32-1.7.4-VC6 (PHP V5.3.5, Apache/2.2.17, Windows 7), using all OpenEMR suggestions during the install, on the very first patient, very first visit, it puts 11 in the form_id field in the forms table.
Wanted to add that if I change the 11 to a 1, it works fine. I create a second vist, and the form_id gets set to 14.
These visits show up in Visit History list, but when I view the encounter the information does not show.
Is there a way to easily compare the config settings for different platforms? This seems like a config setting but this type of error only seems to be happening for the “New Patient Encounter” as far as I can tell. I just can’t seem to find which config setting it is!
I have encountered this error before and found that there is a bug in that confused the Execute method in adodb.inc.php to return an invalid last_insert_id causing the ID issues when audit logging is turned on, which is on by default now. I had to tweak sql.inc and adodb.inc.php to address and save the correct ID. (Tony, you may recollect this
Am curious if it does correct if turn off the logging engine at Administration->Globals->Logging->‘Enable Audit Logging’ . If it is indeed the logging engine, then this is a nasty bug that has occasionally creeped up several times. Hopefully not the case here.
rnagul, what OpenEMR version did you fix this bug in?
Also, what xampp version are you using (OpenEMR only has been confirmed to work with version 1.7.3 and below)?
I have the same problem on Windows 7 with the recommended versions of Apache etc configured. When I try to edit an encounter it ALWAYS brings up a new form instead of the existing encounter. I have also had this issue in the Review of System Checks and any other form added to encounters with the Exception of ROS and SOAP which correctly load the form that was attached to the original encounter.
Is this a Windows specific issue and if so is there a workaround or a fix available
Sorry I forgot that when initially saving and encounter it changes the Encounter date immediately after the save to 1969-12-31 this changes to the correct date on subsequent views but regardless of client the encounter date is ALWAYS Dec 31 1969 when creating the encounter or when trying to save an edited encounter which is currently not possible as it generates a new encounter form on each attempt to edit
I turn off “Enable Audit Logging”, restart everything, and it seems to work fine. Great suggestion!
If you can send me the sql.inc and adodb.inc.php (or tell me where to download them) I can test it to see if I can get it working with Audit turned on.
This is a nasty bug; it sounds like it’s dependent on the php version since there have been no bug reports with users of the xampp-openemr package (uses an older 1.7.3 xampp version). Would be very helpful to get the following:
1. guanacolibre’s xampp version that was used above
2. the modified sql.in and adodb.inc.php files (feel free to email to brady@sparmy.com ) and what version of OpenEMR these files were modified from
I’m unable to test this on my system for the next week or so. Things that would be helpful:
1. If a user that is using the xampp-openemr 4.1 package chimed in and stated this bug was not happening on their system.
2. Have guanacolibre try out the mods from Ramesh
If this were the only bug stopping the more current XAMPP packages from being compatible with OpenEMR, then fixing this bug will be very useful.
I am wondering if the encounter weirdness is related to the fact that setencounter in encounters.inc tries to use a date based value if no parameter is passed. The ultimate query where it checks to see if an encounter was created for the day still looks like it tries to compare to the bigint(20) encounter field in the forms table even though it’s getting a date string. I could see this behaving differently on different xamp packages hence the difference in behaviors.
From: encounters.inc
function setencounter($enc) {
$return_val = 1;
global $encounter;
global $pid;
if ($enc == "" ) {
$enc = date("Ymd");
if (getFormByEncounter($pid,$enc)) {
//there is an encounter enterred for today
} else {
//addForm($enc, "New Patient Encounter", 0, $pid, 1);
$return_val = 0;
}
}
$_SESSION['encounter']=$enc;
$encounter=$enc;
//returns 1 on successful global set, or 0 if there was no
//current encounter, signifying that the interface should load
//the screen for a new encounter
return $return_val;
}
from forms.inc
unction getFormByEncounter($pid,$encounter, $cols="form_id, form_name", $name="")
{
$arraySqlBind = array();
$sql = "select $cols from forms where encounter = ? and pid=? ";
array_push($arraySqlBind,$encounter,$pid);
if(!empty($name)){
$sql .= "and form_name=? ";
array_push($arraySqlBind,$name);
}
// This puts vitals first in the list, and newpatient last:
$sql .= "ORDER BY FIND_IN_SET(formdir,'vitals') DESC, date DESC";
$res = sqlStatement($sql,$arraySqlBind);
for($iter=0; $row=sqlFetchArray($res); $iter++)
{
$all[$iter] = $row;
}
return $all;
}
Brady,
That change though simple looks a little scary to me. (Fear of the unknown), as it doesn’t really explain why the problem occurs in the first place, or why it works with audit logging off.
Anyway, here’s some relevant code snipets to consider.
From sql.inc
// ViSolve: Create a seperate function for audit log calls.
// The audit calls are handled through separate function.
// Before the audit calls are executed, the mysql_insert_id() is stored in GLOBALS['lastiddao']
// and used in the relevant places, i.e in the mysql adodb driver files..
// Note: This GLOBAL variable gets its value only when the audit is enabled.
function sqlInsertClean_audit($statement)
{
// Get the mysql_insert_id() before the execution of the log statement
//$lastid=mysql_insert_id($GLOBALS['dbh']);
//$GLOBALS['lastidado']=$lastid;
// when audit is enabled and $GLOBALS['lastidado'] is not set, then set the GLOBALS irrespective of dbh and adodb handlers.
// ViCarePlus :: Fix for Audit logging Issue :: Sep 24,2010 .
// Issue:: The LAST_INSERT_ID of the audit log table overrides the value in the $GLOBALS['lastidado'] variable.
// In a single transaction, when more than one query is being executed, this issue happens.
// Fix: This code has been taken care by the function auditSQLEvent() in log.inc file
// if ($GLOBALS['lastidado'] > 0)
// { /* do nothing */ }
// else {
// $lastid=mysql_insert_id($GLOBALS['dbh']);
// $GLOBALS['lastidado']=$lastid;
// }
//----------run a mysql insert, return the last id generated
$ret = mysql_query($statement, $GLOBALS['dbh']);
if ($ret === FALSE) {
HelpfulDie("insert failed: $statement", mysql_error($GLOBALS['dbh']));
}
}
from log.inc
function auditSQLEvent($statement, $outcome)
{
$user = isset($_SESSION['authUser']) ? $_SESSION['authUser'] : "";
/* Don't log anything if the audit logging is not enabled. Exception for "emergency" users */
if (!isset($GLOBALS['enable_auditlog']) || !($GLOBALS['enable_auditlog']))
{
if ((soundex($user) != soundex("emergency")) && (soundex($user) != soundex("breakglass")))
return;
}
// ViCarePlus : Fix for Audit Issue :: Sep 24, 2010
// Issue: When the audit logging is enabled and when SELECT QUERY (query=1 in globals.php) is enabled to log,
// the issue of LAST_INSERT_ID arises.
// This is because, the function sql_checksum_of_modified_row() is triggered more than
// once for SELECT Queries and thus the expected value (LAST_INSERT_ID) in the $GLOBALS['lastidado'] is getting altered.
// Since, the $GLOBALS['lastidado'] is manipulated by the other function calls(sql_checksum_of_modified_row),
// this issue is arised.
// Fix:
// The task of assigning LAST_INSERT_ID to a global variable $GLOBALS['lastidado'] is moved from sql.inc to this file.
// Following code will get executed, when (a) when audit is enabled (b) When break glass is invoked.
// Retrieve LAST_INSERT_ID and assign it to a global variable and eventually it can be used by other functions.
$lastid=mysql_insert_id($GLOBALS['dbh']);
$GLOBALS['lastidado']=$lastid;
// ViCarePlus : Audit fix - ends here :: Sep 24,2010