
waldo at vqronline
Oct 27, 2009, 11:24 AM
Post #2 of 15
(1375 views)
Permalink
|
|
Re: "precision" = 'precision' MySQL Error
[In reply to]
|
|
Folks, Ah, the surest way to make process when debugging is to e-mail a group about it, isn't it? :) Of course, the entire MySQL string *is* listed, and the problem appears to twofold. Not only should "precision" be in `backticks` (because it's a reserved term in MySQL's vocabulary) but, again, precision should not equal the text "precision," and instead should be an integer. Is this right? Best, Waldo On Oct 27, 2009, at 1:58 PM, Waldo Jaquith wrote: > Folks, > > In anticipation of v2.0 being finished, I'm returning to my two- > years-on-hold project of moving VQR to Bricolage. Having installed > the latest development release (v1.11.1) for its MySQL support, I'm > having some trouble. I'm unable to add any new subelements, with all > attempts failing like such: > > Unable to execute SQL statement: DBD::mysql::st execute failed: You > have an error in your SQL syntax; check the manual that corresponds > to your MySQL server version for the right syntax to use near > '"precision" = 'precision', cols = '40', rows = '4', length = '0', > vals = '', mul' at line 1 [.for Statement "UPDATE field_type SET > element_type__id = ?, name = ?, key_name = ?, description = ?, place > = ?, min_occurrence = ?, max_occurrence = ?, autopopulated = ?, > max_length = ?, sql_type = ?, widget_type = ?, "precision" = ?, cols > = ?, rows = ?, length = ?, vals = ?, multiple = ?, default_val = ?, > active = ? WHERE id=?" with ParamValues: 0='1', 1='Deck', 2='deck', > 3='A one-sentence teaser or subhead.', 4='1', 5='1', 6='1', 7='0', > 8='256', 9='short', 10='textarea', 11='precision', 12='40', 13='4', > 14='0', 15='', 16='0', 17='', 18='1', 19='12'] at /usr/local/ > bricolage/lib/Bric/Util/DBI.pm line 1 136, <GEN17> line 783.\n, > referer: http://webhosting37.bnsi.net:8080/admin/profile/element_type/1 > > That's just a fragment of the query, of course; there's any way to > see the entire SQL string, I don't know what it is. To my eyes, the > problem seems quite clearly to be "precision" = 'precision'— > field_type.precision is defined as smallint(6), so attempting to set > precision to the textual value of "precision" *should* fail. Note > that the Deck is not the subelement that I'm trying to add—the > failed query is (apparently) coming from Bricolage trying to update > that existing custom field at the same time as I try to add a new > field. Searching through Lighthouse, I see no record of this as a > known bug, although I find it tough to believe—if I understand > what's going on—that this could have gone unnoticed. > > Any ideas? > > Best, > Waldo
|