> I'm not sure it really matter that this query form get the
> id 102.
>
> Would not it work if you replace 102 in
> update/1.0.8/voting-system.sql by an
> unused number?

Well, you're the author of this code, aren't you? :)

> BTW, strangely enough, there are at least one project using
> a non standard query form and there was no issue to get the
> voting system in place.

Interesting, what is the first non-default query-form ID, at Gna! ?
The code in editqueryforms.php doesn't seem to generate the ID itself, delegating that task to MySQL, so I should have used #102 at first glance.

> Maybe we should use 99 as id for this query form, it would
> avoid the issue; we have to check first whether it would not
> implies that this field get shown in first place (that would
> not be nice).

I never understood why every ID starts at 100. Do you know about this?

Also I don't think reserving a fixed set of IDs is a good solution.

Adding a new query form in a generic way would better be done using a Perl or PHP script.

I have no clue about the order issue. I guess it takes whatever order MySQL uses, which may be sorted by ID by default. Adding an index may be the way to cleanly fix this if that's needed.

ERROR 1062 at line 37: Duplicate entry '102' for key 1

In Savannah some people created new query forms, so 102 isn't free.
This is a very rarely used feature (48 at Savannah), so maybe you don't have any here.

Anyway you can't reserve another one for default. The default table_bugs_report.initvalues is incompatible with older installs now.