OperationalError: near ",": syntax error

[yevhen.duma@…]

Trac detected an internal error: OperationalError: near ",": syntax error This is probably a local installation issue.

Found a bug in Trac?

If you think this should work and you can reproduce the problem, you should consider creating a bug report.

Note that the Trac-jsGantt plugin seems to be involved. Please report this issue to the plugin maintainer.

Before you do that, though, please first try searching for similar issues, as it is quite likely that this problem has been reported before. For questions about installation and configuration of Trac or its plugins, please try the mailing list instead of creating a ticket.

Otherwise, please a new bug report describing the problem and explain how to reproduce it.

Python Traceback

Most recent call last:

File "/usr/local/lib/python2.6/dist-packages/Trac-1.0.1-py2.6.egg/trac/web/main.py", line 497, in _dispatch_request
File "/usr/local/lib/python2.6/dist-packages/Trac-1.0.1-py2.6.egg/trac/web/main.py", line 214, in dispatch
File "/usr/local/lib/python2.6/dist-packages/Trac-1.0.1-py2.6.egg/trac/ticket/web_ui.py", line 180, in process_request
File "/usr/local/lib/python2.6/dist-packages/Trac-1.0.1-py2.6.egg/trac/ticket/web_ui.py", line 465, in _process_newticket_request
File "/usr/local/lib/python2.6/dist-packages/Trac-1.0.1-py2.6.egg/trac/ticket/web_ui.py", line 1289, in _do_create
File "/usr/local/lib/python2.6/dist-packages/Trac-1.0.1-py2.6.egg/trac/ticket/model.py", line 256, in insert
File "/usr/local/lib/python2.6/dist-packages/Trac_jsGantt-0.10_r12998-py2.6.egg/tracjsgantt/tracpm.py", line 2943, in ticket_created

Configuration (trac.ini):

[TracPM]
date_format = %Y-%m-%d
days_per_estimate = 0.125
default_estimate = 4.0
estimate_pad = 0.0
fields.estimate = estimatedhours
fields.finish = userfinish
fields.parent = parents
fields.percent = complete
fields.pred = blockedby
fields.start = userstart
fields.succ = blocking
fields.worked = totalhours
goal_ticket_type = milestone
hours_per_estimate = 1
parent_format = %s
userfinish = text
userfinish.label = Planned Finish
userstart = text
userstart.label = Planned Start
complete = select
complete.label = % Complete
complete.options = |0|5|10|15|15|40|50|60|75|80|90|95|99|100
complete.order = 3
complete.value = 0

[trac-jsgantt]
days_per_estimate = 0.125
fields.estimate = estimatedhours
option.caption = Resource
option.colorby = priority
option.comp = 0
option.datedisplay = yyyy-mm-dd
option.dur = 0
option.enddate = 1
option.expandclosedtickets = 1
option.format = month
option.formats = day|week|month|quarter
option.hoursperday = 8.0
option.lwidth = 300
option.omitmilestone = 0
option.openlevel = 0
option.res = 0
option.schedule = asap
option.showdep = 1
option.startdate = 0
option.usermap = 0
fields.start = userstart
fields.finish = userfinish
fields.percent = complete
fields.parent = parents

Thank you!

[yevhen]

Error on ticket creation.

[Ryan J Ollos]

The stacktrace seems to end at the call to rescheduleTickets in ticket_created, but the error must be coming from within rescheduleTickets, from where one of the SQL statements is executed.

It seems like more info is needed about how to reproduce, unless Chris already has an idea of what the issue might be.

yevhen:

• What database are you running?
• Can you describe in more detail the steps to reproduce?

[yevhen]

Hello,

Thank you for quick response. All I did - just install Trac jsGantt plugin (according to TracJsGanttPlugin#Installation). As you see from trac.ini I have used same configuration as in manual.

But I found that during ticket creation it tell that there is no complete custom field, that's why

complete = select
complete.label = % Complete
complete.options = |0|5|10|15|15|40|50|60|75|80|90|95|99|100
complete.order = 3
complete.value = 0

was added.

Now I receive this error during new ticket creation. DB - sqlite, please tell if you need more details and how to get them.

Thank you Yevhen

[yevhen]

also track-admin upgrade tell that Database is up to date, no upgrade necessary.

[Ryan J Ollos]

Thanks, that's some good info to try to reproduce the issue. I will try to reproduce, but I won't be able to do that until a bit later today.

[yevhen]

Thank you! Feel free to ask if you need more details.

[Chris Nelson]

Try disabling the TicketRescheduler component of the plugin.

Ryan is right that this seems to be database-specific. Please let me know if you're using MySQL, SQLite, PostgreSQL, etc.

[yevhen]

Hello,

Thank you!

file trac.db trac.db: SQLite 3.x database

The following component has been disabled: TicketRescheduler (tracjsgantt.tracpm.*)

When it disabled it works.

Thank you Yevhen

[Oscar Andreasson]

Hi,

Just to let you know, having the same issue as of today for some reason. I get the issue upon updating tickets blockedby attribute. Using sqlite3 db. If i disable ticketrescheduler the problem goes away. Re-enabling the ticketrescheduler and the problem comes back.

I'm aware that I have some crap data in the custom fields (some users are not aware of limitations such as not using ~ in remaining time and so forth and there is no sanitation of this data). Could this be affecting?

[Oscar Andreasson]

Actually, I think it may be a related problem but not the same. Enabling/Disabling the ticketRescheduler does fix the issue, but stack trace is different, and it happens on updates. Created a separate ticket for my issue at #11139

[jolyon@…]

Just spun up a new development server on CentOS 6.4 and used the epel Trac 0.12.5-1 release, same as our previous development server. Some of the other plugins upgraded, so moved to newer versions of TracMasterTickets, SubTickets, DateField and Burndown and what-the-heck I updated jsGantt to 0.10-r12899 I think it was (even though the svn tree says 0.11)

Had this exact error and tried updating the config settings for jsGantt plugin but no dice. Simply reverting to the previous release I installed earlier this year r12565 fixed the problem with no configuration changes required.

I am going to agree with a previous poster that the problem is like SQL query related with a variable typo or incomplete migration to new variable name or structure.

Any way, it certainly looks like a code rev between r12565 and latest introduced this buggy behavior related to the rescheduling operation.

[jolyon@…]

sorry, typo in my last post - r12998 was the latest version I tried and had this issue with, reverting to r12565 cured the problem. I only see these files having changed between versions:

A 0.11/tracjsgantt/db_default.py U 0.11/tracjsgantt/htdocs/jsgantt.js U 0.11/tracjsgantt/tracjsgantt.py U 0.11/tracjsgantt/tracpm.py

(going from r12565 to r12998)

[Chris Nelson]

Closing this as a duplicate of #11139 where I've just added some notes (though I don't see how this is failing in either location).