 |
Please check if the case described in this thread applies: http://www.freelists.org/post/racktables-users/Lost-Hardware-Warranty-expiration-dates-after-upgrade,1 |
 |
I do not think that the case you offered matches my case. We have not lost the expiration dates that were input before the upgrade. These dates are still in place. If I were to try to update any of the existing dates, the field would simply clear to nothing. If I were to try to update the field with an invalid format, I do get an error about the format not being correct. If I have SW or HW warranty or both values filled out and I attempt to make ANY edit at all to the Properties page of an object, the date values will clear to empty fields. For an existing server that has not been touched since the upgrade the database values still seem alright. Here is an example. mysql> select * from AttributeValue where object_id=404; +-----------+------------+---------+--------------------------------------+------------+-------------+ | object_id | object_tid | attr_id | string_value | uint_value | float_value | +-----------+------------+---------+--------------------------------------+------------+-------------+ | 404 | 4 | 2 | NULL | 1687 | NULL | | 404 | 4 | 3 | blah.blahinc.com | NULL | NULL | | 404 | 4 | 4 | NULL | 443 | NULL | | 404 | 4 | 22 | NULL | 1487376000 | NULL | | 404 | 4 | 25 | 44454C4C-4D00-104D-8039-B6C04F325031 | NULL | NULL | +-----------+------------+---------+--------------------------------------+------------+-------------+ 5 rows in set (0.00 sec) mysql> Once I make any edit to such a server though, the HW and/or SW Warranty date information will be clears from the database. Also, to repeat, mysql bin logs do not show any input from the GUI triggered query to the date values. Here is what the bin logs look like for a non working update versus a working one. NON-WORKING (HW Warranty Expire was Input): #140130 19:03:51 server id 1 end_log_pos 378 Query thread_id=1 exec_time=0 error_code=0 use `racktables_db`/*!*/; SET TIMESTAMP=1391097831/*!*/; UPDATE Object SET name='BLAH', label='BLAH', has_problems='no', asset_no='USM706010R', comment=NULL WHERE id='148' /*!*/; # at 378 #140130 19:03:51 server id 1 end_log_pos 550 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1391097831/*!*/; SET @@session.time_zone='SYSTEM'/*!*/; INSERT INTO ObjectHistory SELECT *, CURRENT_TIMESTAMP(), 'kkirby' FROM Object WHERE id='148' /*!*/; # at 550 #140130 19:03:52 server id 1 end_log_pos 669 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1391097832/*!*/; DELETE FROM RackThumbnail WHERE rack_id='135' /*!*/; # at 669 #140130 19:03:52 server id 1 end_log_pos 696 Xid = 28 COMMIT/*!*/; DELIMITER ; # End of log file WORKING (HW Warranty Expire is Edited Here): #140130 18:06:22 server id 1 end_log_pos 4792 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; UPDATE Object SET name='BLAH', label='BLAH', has_problems='no', asset_no='USM706010R', comment=NULL WHERE id='148' /*!*/; # at 4792 #140130 18:06:22 server id 1 end_log_pos 4964 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; INSERT INTO ObjectHistory SELECT *, CURRENT_TIMESTAMP(), 'kkirby' FROM Object WHERE id='148' /*!*/; # at 4964 #140130 18:06:22 server id 1 end_log_pos 5103 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; DELETE FROM AttributeValue WHERE object_id='148' AND attr_id='14' /*!*/; # at 5103 #140130 18:06:22 server id 1 end_log_pos 5241 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; DELETE FROM AttributeValue WHERE object_id='148' AND attr_id='3' /*!*/; # at 5241 #140130 18:06:22 server id 1 end_log_pos 5380 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; DELETE FROM AttributeValue WHERE object_id='148' AND attr_id='22' /*!*/; # at 5380 #140130 18:06:22 server id 1 end_log_pos 5563 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; INSERT INTO AttributeValue (uint_value, object_id, object_tid, attr_id) VALUES ('1234483200', '148', '4', '22') /*!*/; # at 5563 #140130 18:06:22 server id 1 end_log_pos 5702 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; DELETE FROM AttributeValue WHERE object_id='148' AND attr_id='26' /*!*/; # at 5702 #140130 18:06:22 server id 1 end_log_pos 5840 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; DELETE FROM AttributeValue WHERE object_id='148' AND attr_id='1' /*!*/; # at 5840 #140130 18:06:22 server id 1 end_log_pos 5979 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; DELETE FROM AttributeValue WHERE object_id='148' AND attr_id='28' /*!*/; # at 5979 #140130 18:06:22 server id 1 end_log_pos 6118 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; DELETE FROM AttributeValue WHERE object_id='148' AND attr_id='21' /*!*/; # at 6118 #140130 18:06:22 server id 1 end_log_pos 6301 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; INSERT INTO AttributeValue (uint_value, object_id, object_tid, attr_id) VALUES ('1266019200', '148', '4', '21') /*!*/; # at 6301 #140130 18:06:22 server id 1 end_log_pos 6440 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; DELETE FROM AttributeValue WHERE object_id='148' AND attr_id='24' /*!*/; # at 6440 #140130 18:06:22 server id 1 end_log_pos 6559 Query thread_id=144 exec_time=0 error_code=0 SET TIMESTAMP=1391094382/*!*/; DELETE FROM RackThumbnail WHERE rack_id='135' /*!*/; # at 6559 #140130 18:06:22 server id 1 end_log_pos 6586 Xid = 5059 COMMIT/*!*/; DELIMITER ; # End of log file Thanks kkirby |
|
|
I cannot reproduce this on 0.20.6 but the symptoms resemble a related problem. Could you post the exact value of the DATETIME_FORMAT option (both application default and the per-user value if there is any) as well as the steps to reproduce? Is there any red error message when the update fails? Thank you. |
|
|
Unfortunately I could not wait any longer for the issue to be resolved. I had to revive a 20.3 edition backup and work from that. There were no error messages at all. If I did input the date in the wrong format I WOULD get a red error bar near the top of the page but when I input the date in the correct format the information would just disappear when I saved the changes. I had tried with the default 20.6 datetime format and I also tried changing the format to %m-%d-%Y but I got the same results. The format would successfully change, but imputing data in the correct format would just clear the field. I will likely try an upgrade again in the next few weeks once a few other projects are finished and out of my way. If I still have the problem at that time I will return here and offer any more data you might need. |
|
|
That is not the intended behaviour and it doesn't reproduce on my side yet. What is the exact PHP version on the server? |
|
|
PHP 5.1.6 (cli) (built: May 7 2012 15:02:52) |
|
|
Thank you. Could you try, supposedly on a separate physical or virtual server: 1. replacing all php* packages with php53* packages (or upgrading to CentOS 6, which has PHP 5.3) 2. upgrading RackTables to 0.20.6 3. checking if the bug still reproduces I understand that may take time. If my own troubleshooting delivers some results faster, I will post the information here. However, it may turn out the bug is specific to PHP 5.1. |
|
|
I have installed CentOS 5.10 with its default PHP version (5.1.6) and this particular bug doesn't reproduce with RackTables 0.20.6. It doesn't work normally either, instead I see other date-related bug: http://www.freelists.org/post/racktables-users/Setting-warranty-expiration-dates-doesnt-work Upgrading the PHP packages to release 5.3 resolved the issue stated on the mailing list. In addition, the issue stated in this bug report doesn't reproduce on CentOS 5 PHP 5.3. I tend to consider this a bug of PHP 5.1. Looking forward to receive the feedback requested in the previous comment. |
|
|
Still looking for the feedback. |
|
|
Without further updates I have to assume the issue was specific to PHP 5.1. Please reopen if it reproduces after upgrade to PHP 5.3 as described earlier. Thank you. |
- Anonymous
