<br>What a reactivity !<br>Thank you very much Lee.<br><br>It is exactly the behaviour we need.<br><br>Fabrice<br><br><br><div class="gmail_quote">2012/5/17 Lee Hachadoorian <span dir="ltr"><<a href="mailto:Lee.Hachadoorian+L@gmail.com" target="_blank">Lee.Hachadoorian+L@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fabrice,<br>
<br>
I filed a bug report, and it turns out this has already been fixed in<br>
the development version.<br>
<br>
<a href="http://hub.qgis.org/issues/5608" target="_blank">http://hub.qgis.org/issues/5608</a><br>
<br>
--Lee<br>
<div><div class="h5"><br>
On Wed, May 16, 2012 at 1:39 PM, Lee Hachadoorian<br>
<<a href="mailto:Lee.Hachadoorian%2BL@gmail.com">Lee.Hachadoorian+L@gmail.com</a>> wrote:<br>
><br>
><br>
> On 05/16/2012 02:41 AM, Bernhard Ströbl wrote:<br>
>><br>
>> I agree, so if the user enters a value it should be passed to the database<br>
>> and not discarded. If it violates any database rules postgresql complains<br>
>> anyways. So this could be a bug then.<br>
>>><br>
>>><br>
>>> BTW, I found I could *edit* the primary key field of a table with a<br>
>>> key field typed as serial, but when I tried to add a new feature, any<br>
>>> value entered manually generated a primary key violation. The column<br>
>>> value in QGIS defaulted to nextval('sequence_name'::regclass),<br>
>>> matching the column default in the table definition, but also<br>
>>> generated a primary key violation. When I cleared the field<br>
>>> completely, the row was added with the next available value from the<br>
>>> sequence.<br>
>><br>
>><br>
>> not confirmed here (PostgreSQL 8.4, QGIS 1.7.4)<br>
>> primary key is integer with a nextval('sequence') default<br>
>> adding features the key field defaults to nextval('sequence')<br>
>> case 1) no change => nextval applied<br>
>> case 2) change value => nextval applied (no error, though)<br>
>><br>
>> expected behaviour for case 2) would be to not apply the default<br>
>> shall we file a ticket for this?<br>
>><br>
>> Bernhard<br>
><br>
> OK, I have added a ticket for this behavior. Note that my previous<br>
> complaint--any supplied value generates a primary key violation--was tested<br>
> on Windows. Testing just now on Ubuntu, I observe same behavior as you and<br>
> OP. I have filed the ticket accordingly. I want to retest on Windows, and<br>
> then will amend ticket or file new bug report.<br>
><br>
><br>
>>>>><br>
>>>>> I found a workaround : if I change the field type of the key from<br>
>>>>> integer to bigint then everything works as attended...<br>
>>>>> QGis doesnt tries anymore to give a value when we don't need it.<br>
>>>>> But this is not very logical isn't it?<br>
>>>>><br>
>>>>> Fabrice<br>
><br>
> Fabrice, it seems that QGIS does allow you to edit an existing feature, so<br>
> another workaround would be to add feature, save changes allowing Postgres<br>
> to assign default value from sequence, then edit to change to the desired<br>
> value.<br>
><br>
> --Lee<br>
><br>
> --<br>
> Lee Hachadoorian<br>
> PhD, Earth&  Environmental Sciences (Geography)<br>
> Research Associate, CUNY Center for Urban Research<br>
> <a href="http://freecity.commons.gc.cuny.edu" target="_blank">http://freecity.commons.gc.cuny.edu</a><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
Lee Hachadoorian<br>
PhD, Earth & Environmental Sciences (Geography)<br>
<div class="im">Research Associate, CUNY Center for Urban Research<br>
</div><a href="http://freecity.commons.gc.cuny.edu/" target="_blank">http://freecity.commons.gc.cuny.edu/</a><br>
</blockquote></div><br>