Recent changes to 427: Value '0000-00-00' is not valid for MySQL data type DATE

#427 Value '0000-00-00' is not valid for MySQL data type DATE

2016-06-17T03:43:15.568000Z

This bug is being discussed in the following thread:
https://sourceforge.net/p/openemr/discussion/202506/thread/55600ab2/

#427 Value '0000-00-00' is not valid for MySQL data type DATE

2016-06-14T00:12:30.612000Z

I am thinking that Oleg has the best idea. If there is no disagreement, we can go ahead and make these changes and have them submitted to the community. Are there any objections or unforseen problems that haven't been mentioned?

#427 Value '0000-00-00' is not valid for MySQL data type DATE

2016-05-16T11:49:45.937000Z

I belive that for the tables: amendments, amendments_history, batchcom we can replace 0000-00-00 with CURRENT_TIMESTAMP without touching the code.

insurance_data will require a small fix in the code.

drugs and drug_inventory will require a fix.

Replacing zeros in openemr_postcalendar_events requires a fix.

There's an INSERT INTO automatic_notification clause that needs to be changed as well.

example_patient_data needs to be changed.

#427 Value '0000-00-00' is not valid for MySQL data type DATE

2016-05-16T11:14:30.770000Z

The NO_ZERO_DATE was deprecated in MySQL 5.6 and does nothing in 5.7.

If true support for transactions is a requirement (compatibility with STRICT_TRANS_MODE=on)
, then references to 0000-00-00 would need to be addressed. Either by switching to TIMESTAMP or by using a different default value. How the calendar would treat 1000-01-01 is not something I'm sure about, and there are probably other instances where dates are used with 0000-00-00 that aren't just for the calendar.

There are many other instances throughout the codebase that are incompatible with strict transaction that would need to be addressed which would require thorough analysis and testing. TEXT NOT NULL columns is an issue I vaguely remember encountering in the past when experimenting with strict transactions.

#427 Value '0000-00-00' is not valid for MySQL data type DATE

2016-05-16T10:13:02.024000Z

Group: Release_4.2.1 --> Development_Release

#427 Value '0000-00-00' is not valid for MySQL data type DATE

2016-05-02T05:51:42.507000Z

Hi,

Some info on this here:
http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html

Note this has been indirectly addressed in the most recent codebase where sql_mode is set to '' explicitly in OpenEMR:
https://github.com/openemr/openemr/commit/e7aa71059534321b660eaa9a8e5fda994914c574

-brady

#427 Value '0000-00-00' is not valid for MySQL data type DATE

2016-05-02T05:47:37.527000Z

I believe that whether 0000-00-00 is allowed is a MySQL option. See the documentation for your MySQL version regarding NO_ZERO_DATE and perhaps also "strict mode". It's likely a matter of updating my.ini (Windows) or my.cnf (*nix).

Value '0000-00-00' is not valid for MySQL data type DATE

2016-05-02T05:06:58.697000Z

Following sql are not valid:
openemr/sql/2_8_2-to-2_8_3_upgrade.sql (1 hit)
Line 116: MODIFY date date NOT NULL DEFAULT '0000-00-00',
openemr/sq/database.sql (5 hits)
Line 950: last_notify date NOT NULL default '0000-00-00',
Line 1015: last_notify date NOT NULL default '0000-00-00',
Line 2506: date date NOT NULL default '0000-00-00',
Line 4785: pc_eventDate date NOT NULL default '0000-00-00',
Line 4786: pc_endDate date NOT NULL default '0000-00-00',

Date value '0000-00-00' does not work in MySQL 5.5.49-win32.
It could be fixed by modifying them into '1000-01-01' as min date for MySQL.
If keep using '0000-00-00', then change the data type become TIMESTAMP insteda of DATE

Value '0000-00-00' is not valid for MySQL data type DATE

2016-05-02T05:06:58.697000Z

Ticket 427 has been modified: Value '0000-00-00' is not valid for MySQL data type DATE
Edited By: Oleg Sverdlov (osverdlov)
_milestone updated: u'Release_4.2.1' => u'Development_Release'