During the process of adding new fields to the Demographics Layouts I encountered the following error: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs. I have done some research and understand the root of the error.
The reason I’m posting here is that once that error occurs I am not able to add new patients to the system. I am able to replicate the error and the result. I have tried it on various windows instances. I have not attempted to re-create the problem on a Mac or Linux instances.
The question is: how do I get the database to accept new patients once I remove some fields from the forms to get them under the size limit?
This error should go away after the next release 4.1.1, since it will actually create TEXT fields only when adding new entries. Unclear what you mean.
Is the following happening:
1) Adding new entries in Adminsitraiton->LAyouts->Demographics
2) Getting error
3) Unable to add new patiens
4) Try to remove the previously added fields
5) Still unable to add patients
or
1) Try to remove the previously added fields
2) unable to add patients
Hello Brady. Once I get the error message I am not able to add new patients even if I remove some of the recently added fields. The system acts like the database is hung up. I can enter data on the add-new-user screen but when I click on the “Create New Patient” button nothing happens.
Hello Brady. I have a related question. When creating new fields in one of the LBV forms is it possible to direct in which table the new field should be created?
When I create new fields in the Demographics layout all the new fields are being created in the patient_data table. Some of the fields we need to create are employer related and should be created in the employer_data table.
A concrete example: We are working on a Latin American implementation of OpenEMR for a clinic in a central american country. We have found that in many instance the father does not live with the mother and children. It is necessary for us to track the father independently from the mother and children but still maintain a relationship in the information. So on the Demographics LBV form we would collect employer information specifically for the mother and we would also collect employer information specifically for the father.
I would appreciate any information you could provide on how to specify where new fields should be created when adding fields to LBV forms.
Are you seeing anything in your php error log after you try to save a patient info?
Note the LBV table placement is dependent on the topic (for example demographics topic goes to patient_data and when creating patient forms all go to lbf_data (which is only 3 columns).
Where the entries are placed for each layout topic can’t be changed. All the stuff added to the demographics layout engine is placed in the patient_data table. So, for a child, you need to have father/mother employment information? Then could just create it in demographics layout and not worry about where it goes (ie. the backend). I don’t think there are places that just utilize the employer info (except for when adding a new insurance entry; perhaps other developers could weigh in here).
OK, I figured out the root cause; I was not able to figure out how to fix the failure mode so I just went around it.
The root cause of the problem is when I try to add columns that cause the row byte count exceed the row limit of 65,535 bytes. Exceeding the byte count seems to throw the database into a mode that causes one of the php scripts to get confused (I don’t remember which script but I could probably figure it out if necessary).
The way I dealt with the problem was to go through each field in the patient_data table and change the varchar size to reflect the actual data field size (including the extra three bytes). I also re-used a number of the existing columns because when I tried to remove a number of them we didn’t need (such as ss, driver’s license, etc) the database started to have spasms because many of the fields we wanted to remove were deeply enmeshed in a number of scripts throughout the system.
This brings me to another question:
Have you guys ever considered having different flavors of OpenEMR something along the lines of Ubuntu? The reason I ask is that there are some great opportunities for OpenEMR here in Latin America but OpenEMR’s current incarnation does not fit very well and requires some fairly extensive re-working. A couple of examples of the more salient items that would need to be changed: insurance (could be removed, normally there is no insurance to bill), need 4 fields for names (first name, middle name, paternal last name, maternal last name), etc. Also it would be nice to be able to remove all the HIPAA stuff as it has no bearing on most installations in developing countries.
It would be great if there were a core OpenEMR engine and a set of language and culture specific and country specific modules which could then be applied over the engine. At this point OpenEMR is very USA centric. I would be willing to contribute some effort on this if you guys are interested.
I look forward to hearing from you.
richard
Hopefully this will no longer be a problem in OpenEMR 4.1.1 (plan release in August) since it will now create TEXT sql fields.
Resource-wise, we can barely support one flavor of OpenEMR at this point :) If your willing to contribute effort towards localization, then please feel free to do so. Suggest making a list of the things that you need for your locale and then we can provide guidance of how to implement mechanisms to support it easier from the main codebase.