Re: Backup and Restore of Reviewboard 2.0 failing (mysqldump issues)

2016-07-30 Thread harish varadarajan
Hi Christian, Thanks for looking into this. As suggested by Eric, and per update in your mail, I copied over the SECRET_KEY, and restarted httpd, and now the repositories are accessible and also, the previous review requests created in the older server show up their diff's correcty, which was

Re: Backup and Restore of Reviewboard 2.0 failing (mysqldump issues)

2016-07-30 Thread Christian Hammond
Ah, I see you have another thread on this. I'll respond there. Christian -- Christian Hammond President/CEO of Beanbag Makers of Review Board On Sat, Jul 30, 2016 at 1:12 PM, Christian Hammond wrote: > Hi

Re: Backup and Restore of Reviewboard 2.0 failing (mysqldump issues)

2016-07-30 Thread Christian Hammond
Hi Harish, I'm not sure I fully understand what problems you're hitting, but a couple notes: 1) If you're using a database that was set up on an older instance, then yes, SECRET_KEY must be copied over. If it was not, a number of things like stored database passwords or hosting service auth

Re: Backup and Restore of Reviewboard 2.0 failing (mysqldump issues)

2016-07-29 Thread harish varadarajan
Hi Eric, Thanks for your post, that I could understand the issue that was happening at my reviewboard instance. Did you figure out the solution for this. With your approach to turning the Debug = True, I am currently able to access the repositories / enter the edit screen. But unfortunately,

Re: Backup and Restore of Reviewboard 2.0 failing (mysqldump issues)

2015-10-28 Thread eric
Turns out I've been fighting this issue on and off for several days now. This looks like it is one of those particularly evil bugs. I've captured a lot of details about it below: Situation very similar - I'm using mysqldump to backup a database. In my case, I'm trying to restore to a different

Re: Backup and Restore of Reviewboard 2.0 failing (mysqldump issues)

2014-12-24 Thread Christian Hammond
Hi Daniel, It does look like an encoding conflict. We recommend using UTF-8 for all database encodings, but MySQL generally defaults to latin1. My guess is that this password uses some sort of latin1 character (Õ, from the looks of it), which is failing to be converted to UTF-8. For most of