Bug report #131
|Affected QGIS version:||Regression?:||No|
|Operating System:||All||Easy fix?:||No|
|Pull Request or Patch supplied:||Resolution:||fixed|
|Crashes QGIS or corrupts data:||Copied to github as #:||10190|
When committing PostGIS digitizing changes to database, in case of even a single error in input (value not allowed) all the editing is lost. Too bad for serious work.
#2 Updated by venturato-faunalia-it - about 14 years ago
1 example: ERROR: insert or update on table "fix_2006" violates foreign key constraint "verifica_id_radio"
DETAIL: Key (id_radio,anno)=(1000,2006) is not present in table "radio_usate".
2 example: ERROR: date/time field value out of range:"31/2/2006".
"save changes but keep editing" might be good, but I think it is better if qgis could keep it im memory, asking the user to edit the wrong value.
#5 Updated by Redmine Admin about 14 years ago
The following error now appears (twice) when committing:
ERROR: syntax error at or near "," at character 318
From the database side, we get:
WARNING: non c'è nessuna transazione in corso
ERROR: current transaction is aborted, commands ignored until end of transaction block
As a result, no data can be input.
#8 Updated by venturato-faunalia-it - about 14 years ago
- Resolution deleted (
- Status changed from Closed to Feedback
Further testing: the situation is already much better than before, but in my view the correct behaviour would be for the program to stop and display the alphanumumeric digitizing window of the wrong record, so that the user could put the correct values.
Admittedly, in case of errors in multiple records this would be difficult to implement. Perhaps better to automatically commit every record just after insertion?
Additionally, we get frequent crashes while digitizing.
#10 Updated by Brendan Morley - about 14 years ago
- Status changed from Feedback to Open
The kind of refinement described in 08/29/06 15:53:14 is no longer a trivial change, and so I will push back that aspect of it to a post-0.8 timeframe.
Even then it would be fairly difficult to address any more than the first error in a commit. Maybe for each change, the postgres provider could do a BEGIN / UPDATE x where y / ROLLBACK sequence (testing to see if the UPDATE worked but without committing the change), but this would be unique to the postgres provider.
Therefore an architectural approach should be made to this instead of a quick fix.
#11 Updated by Jürgen Fischer over 12 years ago
- Status changed from Open to Closed
- Resolution set to fixed
seems this was reintroduced at some point, but:
Editing is not stopped when a commit failure happens and the data is therefore not lost (fixed in c65aee64 (SVN r8211)).
If the commit failure is caused by invalid values (e.g. strings in a numeric column) you can correct them in the attribute table and retry the commit afterwards (fixed in bd9f43f1 (SVN r8212)).