New to OEMR, I did some custom mods in the demographics page, deleting some unused fields and adding a few of my own. Made a few custom lists. All the changes seemed to work correctly, but after logging back in, all I see on my calendar window is the error line “Unknown column ‘pd.pubpid’ in ‘field list’”.
Running 4.1.1 under Windows. I don’t recall changing anything that resembles those columns.
Classic mistake. Never delete any fields from the patient demographic table. pubpid is very specifically required. IF you want to hide fields, use the layout controls to mark them as ‘unused’
–Tony
You should try to download from demo version an upload in you local version. Or just open two OpenEMR same version, in two BrowserWindows one working Demo and the other your own local OpenEMR version, than reconstruct via compare in PHPMyAdmin.
Pimm’s suggestion of a side-by-side comparison and manual correction would work if the patient population is less than 20. Most practices have hundreds if not thousands of patients, making it a Herculean task. The other problem with using the Demo as a guide is that as the day progresses, the 4.1.1 Demo can look pretty bizarre.
Even with a re-install of XAMPP-OpenEMR, the corrupted database will be introduced again, thereby gaining nothing.
Is there a pre-customization backup to which current data can be reconstructed? Is this even feasible? If not, this could be a situation wherein the DIY-er would have to enlist professional support.
Dr. Speck,
You most likely deleted the “External ID” column from the demographics layout. If you add back a column with the ID “pubpid” from the Layout Editor this might be all you need to restore functionality. Hopefully it’s just this one field that you deleted.
There is no canonical procedure to restore a “damaged table,” but there are other methods to try if recreating the missing column with the layout editor doesn’t work. The best method would be if you have backup files from before you customization effort.
As Tony said, this is a common way that OpenEMR’s flexibility can create problems. A strong warning about this potential issue might keep a lot of people out of trouble in the future.
It is not just one table - you will need the form(s) and partial data restoration. Efforts not worth for a test installation. If it is your live data, it gets tricky.
REMEMBER for Future installs: make a backup before changes.
If there was no reason for backup, than just change an continue and just insert the Column in the table and fill the Column with the ColumnName ‘pd.pubpid’ be sure to make this Column with the same parameters as in the Demo version.
If you miss more columns, just add these columns too. Or fill them with the Backup or start from scratch en never delete anything in Demographics Layout. Just do not ACTIVATE or make them INACTIVE.
I misunderstood Pimm’s suggestion. I thought that the correction would occur from the Browse tab (attachment 1) and that would take a mighty long time.
If you go to Database, you should be in the Structure tab to begin with; insert the missing items, using the 4.1.1 Demo as a guide, preferably early in the morning, (attachment 2); it may work out as Kevin and Tony suggested.
While PHPMyAdmin to add the column back ought to work restore the broken functionality, as MD Support Mentioned, deleting a column with the layout editor impacts more than just the patient_data (pd) table. Therefore It may be simpler to reverse the deleted column with the tool originally used in the first place, namely the layout editor.
If this screen and the entry #5 (pubpid/external id) look familiar to you Dr. Speck, then you should be able to fix your system by recreating the entry. You may need to add back other entries that you might have deleted (hence people talking about referencing the demo as a guide to see all the original columns), but this might be the only column you need to deal with.
Thanks you to all who replied. I haven’t been able to work on this until this afternoon.
As suggested by FSGL, I added a field of pubpid to the demographics layout, and the calendar now appears. As I don’t see any application for the field in my practice, I set it to “unused”. Coming from the mindset of assembly language programming on a 4 MHz Z-80 with 64K of ram, a database littered with irrelevant fields was anathema to me. Now, I know better.