Mailing List Archive: Problem after OS upgrade from 12.3 to 13.2 openSUSE

Problem after OS upgrade from 12.3 to 13.2 openSUSE

Feb 11, 2015, 4:09 PM

Post #1 of 6 (2008 views)

Hi,

Everything seems to be working exept the userdb stuff. There was a MySQL
version update.

This is what I am seeing in the interchange log

208.110.143.17 MHe5oMoH:208 - [11/February/2015:14:54:57 -0700]
lyndistributing /cgi-bin/lyndistributing/ord/finalize.html set_row error
as called by Vend::Table::DBI: DBD::mysql::db do failed: Field 'password'
doesn't have a default value at
/usr/local/interchange/lib/Vend/Table/DBI.pm line 1399.
>
> fields=username
> values='U01675'
208.110.143.17 MHe5oMoH:208 - [11/February/2015:14:54:57 -0700]
lyndistributing /cgi-bin/lyndistributing/ord/finalize.html set_row error
as called by Vend::Table::DBI: DBD::mysql::db do failed: Field 'password'
doesn't have a default value at
/usr/local/interchange/lib/Vend/Table/DBI.pm line 1399.
>
> fields=username
> values='U01675'
208.110.143.17 MHe5oMoH:208 - [11/February/2015:14:54:57 -0700]
lyndistributing /cgi-bin/lyndistributing/ord/finalize.html Safe:
Auto-create of user failed. at (tag 'perl') line 1.
>
> die errmsg("Auto-create of user failed.");
>
208.110.143.17 MHe5oMoH:208 - [11/February/2015:14:54:57 -0700]
lyndistributing /cgi-bin/lyndistributing/ord/finalize.html Route log
failed.
208.110.143.17 MHe5oMoH:208 - [11/February/2015:14:54:57 -0700]
lyndistributing /cgi-bin/lyndistributing/ord/finalize.html ERRORS on ORDER
:
> Error during creation of order routing log:
> Route log failed. at /usr/local/interchange/lib/Vend/Order.pm line 1844.

Any ideas?

Thanks,

--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Re: Problem after OS upgrade from 12.3 to 13.2 openSUSE [ In reply to ]

peter at pajamian

Feb 11, 2015, 6:34 PM

Post #2 of 6 (1985 views)

Permalink

On 02/12/2015 01:09 PM, Boyd Lynn Gerber wrote:
> Everything seems to be working exept the userdb stuff. There was a
> MySQL version update.
>
> 208.110.143.17 MHe5oMoH:208 - [11/February/2015:14:54:57 -0700]
> lyndistributing /cgi-bin/lyndistributing/ord/finalize.html set_row error
> as called by Vend::Table::DBI: DBD::mysql::db do failed: Field
> 'password' doesn't have a default value at
> /usr/local/interchange/lib/Vend/Table/DBI.pm line 1399.

By the looks of it, either (1) the newer version of MySQL has a minor
incompatibility with the older version where you now have to have a
default value when a field is left blank instead of just assuming it's
NULL, or (2) when you transferred teh db over the default setting for
the field didn't transfer with it.

I would try this in the mysql shell:
ALTER TABLE userdb ALTER password SET DEFAULT '';

After that the error should go away.

Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Re: Problem after OS ... New Error after doing your suggestion. [ In reply to ]

gerberb at zenez

Feb 11, 2015, 8:52 PM

Post #3 of 6 (1980 views)

Permalink

On Thu, 12 Feb 2015, Peter wrote:
> On 02/12/2015 01:09 PM, Boyd Lynn Gerber wrote:
>> 208.110.143.17 MHe5oMoH:208 - [11/February/2015:14:54:57 -0700]
>> lyndistributing /cgi-bin/lyndistributing/ord/finalize.html set_row error
>> as called by Vend::Table::DBI: DBD::mysql::db do failed: Field
>> 'password' doesn't have a default value at
>> /usr/local/interchange/lib/Vend/Table/DBI.pm line 1399.
>
> By the looks of it, either (1) the newer version of MySQL has a minor
> incompatibility with the older version where you now have to have a
> default value when a field is left blank instead of just assuming it's
> NULL, or (2) when you transferred teh db over the default setting for
> the field didn't transfer with it.
>
> I would try this in the mysql shell:
> ALTER TABLE userdb ALTER password SET DEFAULT '';

Thanks, no I am getting this error

Failed to record timestamp in UserDB: DBD::mysql::st execute failed:
Incorrect datetime value: '1423715746' for column 'mod_time' at row 1 at
/usr/local/interchange/lib/Vend/Table/DBI.pm line 1741.

--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Re: Problem after OS ... New Error after doing your suggestion. [ In reply to ]

peter at pajamian

Feb 12, 2015, 12:43 AM

Post #4 of 6 (1978 views)

Permalink

On 02/12/2015 05:52 PM, Boyd Lynn Gerber wrote:
> Failed to record timestamp in UserDB: DBD::mysql::st execute failed:
> Incorrect datetime value: '1423715746' for column 'mod_time' at row 1 at
> /usr/local/interchange/lib/Vend/Table/DBI.pm line 1741.

That looks like unitime (seconds after epox) and represents the date,
"Thu Feb 12 04:35:46 2015 UTC". Mysql doesn't recognize unixtime as a
valid input format for datetime formatted fields, hence the problem
you're having. In this case you must have either changed the table
schema for that column from something like varchar to datetime, or
changed code in Interchange that was supposed to translate that
timestamp to a value accepted by mysql.

See http://dev.mysql.com/doc/refman/5.7/en/date-and-time-literals.html
for a description of supported time formats in mysql.

The easiest (but not necessarily the best) solution here to just get
your catalog working again is probably:
ALTER TABLE userdb MODIFY mod_time VARCHAR(20);

Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Re: Problem after OS ... (Solved) [ In reply to ]

gerberb at zenez

Feb 12, 2015, 9:23 AM

Post #5 of 6 (1977 views)

Permalink

SOLVED Thanks

On Thu, 12 Feb 2015, Peter wrote:

> On 02/12/2015 05:52 PM, Boyd Lynn Gerber wrote:
>> Failed to record timestamp in UserDB: DBD::mysql::st execute failed:
>> Incorrect datetime value: '1423715746' for column 'mod_time' at row 1 at
>> /usr/local/interchange/lib/Vend/Table/DBI.pm line 1741.
>
> That looks like unitime (seconds after epox) and represents the date,
> "Thu Feb 12 04:35:46 2015 UTC". Mysql doesn't recognize unixtime as a
> valid input format for datetime formatted fields, hence the problem
> you're having. In this case you must have either changed the table
> schema for that column from something like varchar to datetime, or
> changed code in Interchange that was supposed to translate that
> timestamp to a value accepted by mysql.
>
> See http://dev.mysql.com/doc/refman/5.7/en/date-and-time-literals.html
> for a description of supported time formats in mysql.
>
> The easiest (but not necessarily the best) solution here to just get
> your catalog working again is probably:
> ALTER TABLE userdb MODIFY mod_time VARCHAR(20);

Thanks, That worked for now while I figure out why it suddenly stopped
working. To test everything, I rebuilt the version of perl being used.
Tested and installed it. rebuilt the version of IC it was using. Compare
it to what was being used. Only object or executealbes were different.
Made sure all the individual catalogs were the same. Some where IC must
have been changing unixtime or was getting the information a different
way. For no I have thngs running while I figure it out.

Thanks,

--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Re: Problem after OS ... (Solved) [ In reply to ]

peter at pajamian

Feb 12, 2015, 11:35 AM

Post #6 of 6 (1973 views)

Permalink

On 02/13/2015 06:23 AM, Boyd Lynn Gerber wrote:
>
> Thanks, That worked for now while I figure out why it suddenly stopped
> working. To test everything, I rebuilt the version of perl being used.
> Tested and installed it. rebuilt the version of IC it was using.
> Compare it to what was being used. Only object or executealbes were
> different. Made sure all the individual catalogs were the same. Some
> where IC must have been changing unixtime or was getting the information
> a different way. For no I have thngs running while I figure it out.

FYI, mod_time is stored as a unixtime in my catalogs as well (and is
varchar(20)), os it's probably the field definition that got changed,
not the way that IC is storing the timestamp.

Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users