the notebook you are searching in has been moved or renamed since the saved search was created

(which is not true).

I had this problem, and found a solution.

Go to your Evernote on a client where you can edit saved searches (Windows for me),
edit all the searches, and make sure that notebook name is quoted in the search (and also, possibly, with all proper letter cases).

I found this solution by first creating a search from the web-beta interface, it looked like this: notebook:"Mynotebook" tag:1-now
All the crossed-out searches (despite working totally fine on Windows) looked like this: notebook:Mynotebook tag:1-now
or even like this (note the lower-case 1st letter of the notebook name): notebook:mynotebook tag:1-now.

After editing saved searches and synchronizing, they all appear (and work) just fine in the beta web-interface.

If you cannot edit your searches right now, there is another workaround: all the saved searches work fine for me from the Shortcuts menu (a star in the left panel).

Hope this helps!

I assume that the problem is caused by Google Analytics, namely the “track outgoing clicks” feature (as recalled, might be inaccurate feature name). “Track outgoing links” adds some JavaScript code to all outgoing links, and that script has tick characters like this one ‘ which, incidentally, are also used for delimiting the values of comment anchor tags.

To fix:

1. locate file wp-includes/comment-template.php
2. in that file, find the get_comment_author_link function (lines 140-150 in WP 2.7.1)
3. replace the line
   1. $return = "<a href='$url' rel='external nofollow' class='url'>$author</a>";

   with

   1. $return = '<a href="'.$url.'" rel="external nofollow" class="url">'.$author.'</a>';

This helped me and might help you.

I found the reason at debianhelp.org forums. Basically, it’s the PC speaker module (pcspr) not functioning correctly. I suspect this problem manifests itself only on some types of laptops. The solution is either to somehow reconfigure the pcspkr module, or just disable it. More on how to disable the module below.

First of all, boot into console-only mode or even single-user mode. On my install GRUB loader, configured by the Debian Installer, had an option in the boot menu to boot into single-user mode.

Remember, that any sound emission attempt will freeze your computer in this scenario. So avoid any actions, which might generate a system beep. These actions include (but are in no way limited to): using TAB filename/command autocompletion, using up/down arrows in command line when there is nothing in the history above or below the current command, etc.

After successfully booting, remove the pcspkr module: modprobe -r pcspkr (if that doesn’t work, try rmmod pcspkr). Note, that this command only removes pcspkr module for the current session, and the module will be loaded again on next boot.

To permanently disable the pcspkr module, you can blacklist it. To do so, add the line blacklist pcspkr to the /etc/modprobe.d/blacklist.local file. If this file does not exist, you can create it.

On my system I already had /etc/modprobe.d/blacklist file, so I also added blacklist pcspkr line to that file. I did not check which one actually worked for me, but on the next boot pcspkr didn’t load.

I also did one more thing – configured console not to beep. This is done in /etc/inputrc file by uncommenting the following line: set bell-style visible (or you can uncomment set bell-style none to have absolutely no bell notifications).

There’s also a method to disable IPv6 module, which can be adopted for the pcspkr module. However, I didn’t use it – methods listed above helped me.

References other than already cited: how to disable PC speaker, how to disable PC speaker in Etch.

There are 3 possible solutions: using INSERT IGNORE, REPLACE, or INSERT … ON DUPLICATE KEY UPDATE.

Imagine we have a table:

Now imagine that we have an automatic pipeline importing transcripts meta-data from Ensembl, and that due to various reasons the pipeline might be broken at any step of execution. Thus, we need to ensure two things: 1) repeated executions of the pipeline will not destroy our database, and 2) repeated executions will not die due to ‘duplicate primary key’ errors.

Method 1: using REPLACE

It’s very simple:

If the record exists, it will be overwritten; if it does not yet exist, it will be created.
However, using this method isn’t efficient for our case: we do not need to overwrite existing records, it’s fine just to skip them.

Method 2: using INSERT IGNORE
Also very simple:

Here, if the ‘ensembl_transcript_id’ is already present in the database, it will be silently skipped (ignored). (To be more precise, here’s a quote from MySQL reference manual: “If you use the IGNORE keyword, errors that occur while executing the INSERT statement are treated as warnings instead. For example, without IGNORE, a row that duplicates an existing UNIQUE index or PRIMARY KEY value in the table causes a duplicate-key error and the statement is aborted.”.) If the record doesn’t yet exist, it will be created.

This second method has several potential weaknesses, including non-abortion of the query in case any other problem occurs (see the manual). Thus it should be used if previously tested without the IGNORE keyword.

There is one more option: to use INSERT … ON DUPLICATE KEY UPDATE syntax, and in the UPDATE part just do nothing do some meaningless (empty) operation, like calculating 0+0 (Geoffray suggests doing the id=id assignment for the MySQL optimization engine to ignore this operation). Advantage of this method is that it only ignores duplicate key events, and still aborts on other errors.

As a final notice: this post was inspired by Xaprb. I’d also advise to consult his other post on writing flexible SQL queries.

int main () {
unsigned int i;

for (i = 0; i < 2 ; i++ ) { i = 0; } return 0; } [/c] compiled it and executed several times on the GoDaddy shared hosting server. I did observe the program running for the maximum of 20 seconds of CPU time, not a second more. Please note, that 20 seconds of CPU time can be much more of “real” time, if the script isn’t using 100% of CPU, which often the case for shared hosting. Thus if you have in your php.ini max_execution_time set to, say, 60 seconds, your php script may actually execute as long as one minute; but I’m pretty sure that if your script has lots of CPU-intensive procedures, then as soon as it uses 20 seconds of CPU time, it will be terminated (however, this statement still needs checking – anyone?). To verify, I also created a cron job with the same file. It ran for 30 seconds CPU time. Strangely, this behaviour is not documented anywhere. This limit may also explain a number of other problems, if you have heavy web-applications: they just might be killed before they are finished, causing errors. I do understand the reason for this limitation, and am sure similar limitations exist in other shared hosting environments. The only important thing here is that this limit should have been documented and even put upfront somewhere in the hosting plans descriptions. I also wonder if the limit is the same for all godaddy shared hosting plans, or if it differs. 20 seconds when executed from PHP, and 30 seconds when executed as a cron job were observed on the Deluxe Linux Hosting plan. Extensions, additions and comments are welcome.