Saving or updating schedule settings for has been unsuccessful.

Can you provide more details on how to reproduce?

Yeah let us know if theres something we can do to reproduce, or try the 2.x branch with simplenews 6.x-2.x

@lutra -> Are you still getting this problem on latest dev?

No idea sorry

"Quick and dirty" fix for this issue is as follows (only if you are on MySQL):

change all instances of interval and stop in a query with corresponding simplenews_scheduler.interval and simplenews_scheduler.stop prefixed ones, because INTERVAL and STOP are actual SQL commands.

So the query beginning on line 161 of simplenews_scheduler.module should read:

    $result = db_query("INSERT INTO {simplenews_scheduler} (nid, activated, simplenews_scheduler.interval, start_date, simplenews_scheduler.stop, stop_date, stop_edition, php_eval) 
                             VALUES (%d, %d, '%s', %d, %d, %d, %d, '%s')
                             ON DUPLICATE KEY UPDATE last_run = 0, activated = %d, simplenews_scheduler.interval = '%s', start_date = %d, simplenews_scheduler.stop = %d, stop_date = %d, stop_edition = %d, php_eval = '%s' ", $nid, $activated, $interval, $start_date, $stop, $stop_date, $stop_edition, $php_eval, $activated, $interval, $start_date, $stop, $stop_date, $stop_edition, $php_eval);

Hopefully someone will be able to create corresponding patch quick, marking this as Needs work meanwhile.

I guess the problem is you are using PostgreSQL and I am using MySQL. I am not too good at DB syntax differences, but the problem here is that PostgreSQL does not support ON DUPLICATE KEY construction. The query this module uses is pure MySQL syntax.

Yes, well I guess either way we need to change those fields.

OK I have created two patches

One addresses the bad SQL directly and the other is a general cleanup (uses isset() etc).

It also includes an update hook to attempt to rename the tables.

update: don't use these patches

Just a quick notice on the pgsql patch:

ON DUPLICATE KEY UPDATE last_run = 0, activated = %d, send_interval = '%s', start_date = %d, stop_type = %d, stop_date = %d, stop_edition = %d, php_eval = '%s' ", $nid, $activated, $interval, $start_date, $stop, $stop_date, $stop_edition, $php_eval, $activated, $interval, $start_date, $stop, $stop_date, $stop_edition, $php_eval, $nid);

Does this really needs a $nid at the very end of the line? I believe it's superfluous, since the last modifier used in query is php_eval='%s'

And yeah, it's not going to work on PostgreSQL due to ON DUPLICATE KEY mentioned above.

Yeah I don't know who added that DUPLICATE KEY business, heres an improved patch..

These two patches ("improved sql" and "notify cleans") are contradicting each other - you cannot apply them one after another because each patch messes with part of the code the other patch refers to.

Could you possibly combine them into one patch so we can start testing?

oops

Please just use the patch in #17 I will rework the other patch once this issue is clearedcleared

Last dev. version works ok. Use only patch from #17

Oh, I can see your problem - the patch that dgtlmoon has provided is not a "fair" patch (I won't tell you why :)
Just use the one I attached here.

Try against latest dev, as I've also commited #1192670: 6.x-2.x HTML mail not sent which may help postgres users

Used the Drupal API for finding the "Full HTML" format instead of the silly SQL statement. (It needs to find the full html output filter to set the generated editions to, as they are static)

To lutra: replace "a/simplenews" occurences with "simplenews" and "b/simplenews" with "simplenews" in this patch to apply correctly :)

Found another glitch... which i hope is the last

     case 'view':
       if(isset($node->simplenews_scheduler_edition)) {
         drupal_set_message(t('You have been redirected to the original newsletter'));
         drupal_goto('node/'.$node->simplenews_scheduler_edition['pid'].'/simplenews');
       }
     break;

Seems to be triggering when sending newsletters.

fixed with

+       if(isset($node->simplenews_scheduler_edition) && arg(0) == 'node' ) {

Also, noticed that if you hit cron.php as a authenticated user, it does not unset your $user, so your newsletters can include [edit] etc

Note that arg(0)=='node' is also valid for test sending a newsletter...

OK, well i'm leaving that part out until we figure out a nicer way in the UI to show that you are viewing a generated newsletter and not the original.

Sorry, and this one actually implements the improved function for figuring out the input types instead of the bogus SQL

this contains...

   // Output format for all newly created items should just be Full HTML, incase of Views output etc.
-  if ($format_id = db_result(db_query('SELECT format FROM {filter_formats} WHERE name like "full html"'))) {
+  if ($format_id = _simplenews_scheduler_get_full_html_format() ) {
     $node->format = $format_id;
   }
+  

test against this patch.

This also takes care of lots of warnings if you have your PHP configured to return all notices/warnings for unset variables etc.

Simplenews Schuduler is adding stuff to new created editions of newsletters and shown on my home page when a user want to
enter the site.How can I delete this edition?

that's just how it works, it schedules a new copy of the newsletter to be created - also please post a support issue, not in this thread

committed

Have done a lot of my own testing and seems to work nicely

Cool. Great to see this fixed.