InFailedSqlTransaction

[Gaël Princivalle]

Hi.

Someone knows what it means?

After a server change I'm able in the Admin to modify the table records but not the one of the scheduler.

Any idea?

Traceback (most recent call last):
  File "/home/user/apps/web2py_folder/web2py/gluon/main.py", line 456, in wsgibase
    session._try_store_in_db(request, response)
  File "/home/user/apps/web2py_folder/web2py/gluon/globals.py", line 1251, in _try_store_in_db
    if not table._db(table.id == record_id).update(**dd):
  File "/home/user/apps/web2py_folder/web2py/gluon/packages/dal/pydal/objects.py", line 2686, in update
    ret = db._adapter.update(table, self.query, row.op_values())
  File "/home/user/apps/web2py_folder/web2py/gluon/packages/dal/pydal/adapters/base.py", line 579, in update
    raise e
InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block

[Gaël Princivalle]

We talk about the db.scheduler_task table. I've deleted all the records from this table, and also from db.scheduler_run and db.scheduler_worker.

No way.

[Gaël Princivalle]

I've deleted the scheduler.py file and deleted the scheduler tables.

Now if I add again the scheduler.py file the scheduler tables are in the admin but not in the DB, and the error is the same for all the scheduler tables, InFailedSqlTransaction.

Someone can help me?

[Jim S]

Can you go to the databases directory in your app and delete the scheduler tables from there?  Then make sure your db connection has migrate=True specified along with fake-migrate=False.

I'm thinking that should force a rebuild of the scheduler tables in your database.

-Jim

[Gaël Princivalle]

Thank you Jim.

I've setted migrate to False and fake-migrate to True.

Deleted the scheduler tables in the database folder

Setted migrate to True and fake-migrate to False

And the tables are not rebuild in the DB.

The error still the same.

I'll try to delete the scheduler.py file, export the db, import it in a new db and add again the scheduler...

[Jim S]

Did you go in to the application so that db.py would be executed, thereby triggering the migration to happen?

-Jim

[Gaël Princivalle]

> Did you go in to the application so that db.py would be executed, thereby triggering the migration to happen?

Yes, after each modification of the DB connection string I reload a website page.

I've resolved this problem moving the scheduler tables in another DB.

Thanks for your help.

[Jim S]

I was guessing that you were missing a field in your scheduled_task table.  I don't know when it happened, but at some point an additional field was added to the table.  I'm confused as to why your migrate didn't work though to rebuild everything.  Well, glad you have it all working now.

-Jim