wslymsgrv

Just want to follow up on this issue and say that I decided to upgrade Revive, thinking that maybe a fresh install would solve some of these issues. While I was upgrading Revive from version 3.x to 4.0.2, I hit an issue with not being able to access the admin dashboard due to Varnish cache. I jumped on a chat with Dreamhost about the limitations of their DreamPress product and found out that since it's a managed WordPress type thing, they don't allow any 3rd party tools or software to be installed in a subdirectory, which is why my statistics stopped reporting after the server switch. Thankfully my old shared server is still accessible, so I plopped a new instance of Revive on there and the migration/upgrade process went swimmingly and now I'm back up serving ads as good as new.

@andrewatfornax I ran mysqlcheck and got the following result. Everything appears OK... Table Op Msg_type Msg_text revive_adserver.rv_accounts check status OK revive_adserver.rv_account_preference_assoc check status OK revive_adserver.rv_account_user_assoc check status OK revive_adserver.rv_account_user_permission_asso... check status OK revive_adserver.rv_acls check status OK revive_adserver.rv_acls_channel check status OK revive_adserver.rv_ad_category_assoc check status OK revive_adserver.rv_ad_zone_assoc check status OK revive_adserver.rv_affiliates check status OK revive_adserver.rv_affiliates_extra check status OK revive_adserver.rv_agency check status OK revive_adserver.rv_application_variable check status OK revive_adserver.rv_audit check status OK revive_adserver.rv_banners check status OK revive_adserver.rv_banner_vast_element check status OK revive_adserver.rv_campaigns check status OK revive_adserver.rv_campaigns_trackers check status OK revive_adserver.rv_category check status OK revive_adserver.rv_channel check status OK revive_adserver.rv_clients check status OK revive_adserver.rv_database_action check status OK revive_adserver.rv_data_bkt_a check status OK revive_adserver.rv_data_bkt_a_var check status OK revive_adserver.rv_data_bkt_c check status OK revive_adserver.rv_data_bkt_m check status OK revive_adserver.rv_data_bkt_r check status OK revive_adserver.rv_data_bkt_vast_e check status OK revive_adserver.rv_data_intermediate_ad check status OK revive_adserver.rv_data_intermediate_ad_connect... check status OK revive_adserver.rv_data_intermediate_ad_variabl... check status OK revive_adserver.rv_data_raw_ad_click check status OK revive_adserver.rv_data_raw_ad_impression check status OK revive_adserver.rv_data_raw_ad_request check status OK revive_adserver.rv_data_raw_tracker_impression check status OK revive_adserver.rv_data_raw_tracker_variable_va... check status OK revive_adserver.rv_data_summary_ad_hourly check status OK revive_adserver.rv_data_summary_ad_zone_assoc check status OK revive_adserver.rv_data_summary_channel_daily check status OK revive_adserver.rv_data_summary_zone_impression... check status OK revive_adserver.rv_images check status OK revive_adserver.rv_log_maintenance_forecasting check status OK revive_adserver.rv_log_maintenance_priority check status OK revive_adserver.rv_log_maintenance_statistics check status OK revive_adserver.rv_password_recovery check status OK revive_adserver.rv_placement_zone_assoc check status OK revive_adserver.rv_preferences check status OK revive_adserver.rv_session check status OK revive_adserver.rv_stats_vast check status OK revive_adserver.rv_targetstats check status OK revive_adserver.rv_trackers check status OK revive_adserver.rv_tracker_append check status OK revive_adserver.rv_upgrade_action check status OK revive_adserver.rv_userlog check status OK revive_adserver.rv_users check status OK revive_adserver.rv_variables check status OK revive_adserver.rv_variable_publisher check status OK revive_adserver.rv_zones check status OK

Yes @andrewatfornax I'm a full stack dev preferring vim by day and a "I-don't-have-time-for-this-to-stop-working wordpress freelancer" by night :). Are there any specific tables I should run an OPTIMIZE and REPAIR on? Or all tables?

@andrewatfornax, I haven't run mysqlcheck. Is that something I can run from phpMyAdmin? I don't have SSH access to the server.

Hi @andrewatfornax, It looks like the most recent record on `rv_data_summary_ad_hourly` is indeed from Feb 22. SELECT * FROM `rv_data_summary_ad_hourly` ORDER BY `rv_data_summary_ad_hourly`.`date_time` DESC 2017-02-22 22:00:00 However this table has recent rows on it...like you had me look at before. SELECT * FROM `rv_data_bkt_m` ORDER BY `rv_data_bkt_m`.`interval_start` DESC 2017-04-21 15:00:00 I don't know what other tables I should be looking at or what processes insert into these tables, so I'm open to any ideas you may have. Thanks!

Hi @andrewatfornax, The old server is still in place with access to the same database. However after the code moved to a new server, the DNS changes pointing to the IP address of the new server made the old server inaccessible from the web. So to the best of my knowledge, ads being served should only be executing the revive code on the new server, which is what the debug.log on the new server shows. The old revive code that was running on the old server has a debug.log file that stopped being updated on 2/22/17 when the server switch happened. I thought that meant the old revive code was no longer being excecuted. If that is true then the automated maintenance task should no longer be invoked on the old server, since it's no longer serving ads. Should I just delete all the old revive code just in case? I cleared all the revive cache files on both servers and the new server is still only pulling statistics from before 2/22/17 despite what the debug.log file claims is happening. Also, ads are correctly being served on the web and in emails from the new server.

I'm having this same issue. I followed all the steps on https://documentation.revive-adserver.com/display/DOCS/No+Statistics. I confirmed that `SELECT * FROM rv_data_bkt_m;` is returning recently logged events. I confirmed that automated maintenance is running by checking Global Settings > Maintenance. I also verified that the proper statistics columns are enabled on the user interface settings. I also confirmed the debug.log file on my new server contains recent events. My server switch happened on 2/22/17. On my new server, the revive code was copied over. It's still using the same database server. When I navigate to Preferences > User Log > Maintenance log, the most recent events are from before 2/22/17. So the maintenance log report on my new server seems to be pulling it's information from the old server. This issue also shows up on the Statistics page itself where if I filter by a date older than 2/22/17, I can see statistics, but everything after that is empty. This behavior doesn't match up with the database query results or all the other configuration settings and debug.log file. After the server switch, I updated my config file to the new web root. Am I missing another configuration setting that would tell the Statistics and Maintenance log to pull from the new server instead of the old server???

I'm having this same issue. I followed all the steps on https://documentation.revive-adserver.com/display/DOCS/No+Statistics. I confirmed that `SELECT * FROM rv_data_bkt_m;` is returning recently logged events. I confirmed that automated maintenance is running by checking Global Settings > Maintenance. I also verified that the proper statistics columns are enabled on the user interface settings. I also confirmed the debug.log file on my new server contains recent events. My server switch happened on 2/22/17. On my new server, the revive code was copied over. It's still using the same database server. When I navigate to Preferences > User Log > Maintenance log, the most recent events are from before 2/22/17. So the maintenance log report on my new server seems to be pulling it's information from the old server. This issue also shows up on the Statistics page itself where if I filter by a date older than 2/22/17, I can see statistics, but everything after that is empty. This behavior doesn't match up with the database query results or all the other configuration settings and debug.log file. After the server switch, I updated my config file to the new web root. Am I missing another configuration setting that would tell the Statistics and Maintenance log to pull from the new server instead of the old server???