Thanks for your help with this.  I've added the missing try..catch block here:;a=commitdiff;h=1b14e632845e288fc53110e9b93584088c94b43e

Obviously we could still take this further to support installation to other database platforms (theoretically the rest of the code supports PostgreSQL and possibly Oracle)... but for now I'm content to live with hard-coded MySQL installation and let people with other platforms do a little manual work.

I'm not sure about the double-flash message problem.  I've seen that on a few occasions myself, but I haven't run into it for a while.  Do you have a set of steps to reproduce the problem?

The way the flash messenger works is simple -- the controller adds messages to the object, which persists in the session.  The view renders the messages, and this rendering process also causes messages to get cleared.

One possible way you can end up with double messages is if you go down a path that adds a message but fails before rendering.  If the problem corrects itself, you can get a double message (one from the failed run, one from the successful, rendered run).  However, while you can run into that scenario during coding/troubleshooting, it shouldn't happen under normal circumstances.

- Demian

From: Seaman, Graham []
Sent: Friday, October 26, 2012 5:13 AM
Subject: Re: [VuFind-Tech] vufind2.0 debugging

Demian wrote:


> Are you sure you edited the appropriate config.ini (i.e. local/config/vufind/config.ini, rather than config/vufind/config.ini)?  That might explain why manually entering the SQL failed.


No, I edited the wrong config file. Confused myself by choosing 'local' as the name for any local modifications and so expecting the 'local' directory to be empty. I should have picked a more unique name.


>However, I’m not sure why “skip credentials” would give you an error message.  That’s supposed to generate all the SQL commands without connecting to the database so that you >can copy and paste them.  It does make use of the database connection object in order to do escaping properly… so one possible explanation might be that you’re missing the Mysqli >extension to PHP, and that is the cause of all the exceptions.  If that’s the case, we should probably make the code smarter so that it can offer a more targeted explanation of the >issue.


That was the real problem. It needs a try/catch round the getAdapterFromConnectionString() call on line 326; the catch should set the flashMessenger and return $view - no point continuing if there is no mysql.


Do you know why the FlashMessenger tends to print error messages twice? I've seen this in other ZF applications.


Thanks for the help!