As part of my standard test routine, I've just uploaded two CSV files, changed their primary keys, and created a relationship between them. (Some of the fun I've had changing primary keys is recorded in issues #776 and #777.) I then went into one of the tables, and added a new record.
I was a bit surprised to see this:
The table has two autoincrement fields ('people_index', the primary key field ORDS added when I uploaded the file, and 'id', the one I changed it to). One of them has autoincremented properly; the other (which was supposed to be the primary key) has instead been completed with a 1. This means there are now two records which have a 1 in that column.
When I went back to the schema designer, I found that the table no longer had a primary key. (When I tried to make the 'id' field back into the primary key, it of course wouldn't let me, as that field now contains duplicate values.)
As I'd been having some problems with primary keys previously, I cannot say with absolute certainty that 'id' was actually functioning as the primary key immediately before I made the edit - I thought it was, but it's possible that ORDS hadn't retained my changes (as has happened on other occasions). However, even if it wasn't, an autoincrement field shouldn't behave this way!
I then attempted to reproduce this bug by uploading the same two files to a new database and working through some similar steps. This time, I got this:
So in this database, the autoincrement has worked properly in the 'id' field, but has skipped a number in the 'people_index' field. In this case, the primary key field was still in place when I went back to the schema designer.
This is all happening on Staging, in the project called 'Staging test 2', in the databases 'CSV upload test' and 'CSV upload test 2'. Dave, I'll make you a project admin.
As part of my standard test routine, I've just uploaded two CSV files, changed their primary keys, and created a relationship between them. (Some of the fun I've had changing primary keys is recorded in issues #776 and #777.) I then went into one of the tables, and added a new record.
I was a bit surprised to see this:
The table has two autoincrement fields ('people_index', the primary key field ORDS added when I uploaded the file, and 'id', the one I changed it to). One of them has autoincremented properly; the other (which was supposed to be the primary key) has instead been completed with a 1. This means there are now two records which have a 1 in that column.
When I went back to the schema designer, I found that the table no longer had a primary key. (When I tried to make the 'id' field back into the primary key, it of course wouldn't let me, as that field now contains duplicate values.)
As I'd been having some problems with primary keys previously, I cannot say with absolute certainty that 'id' was actually functioning as the primary key immediately before I made the edit - I thought it was, but it's possible that ORDS hadn't retained my changes (as has happened on other occasions). However, even if it wasn't, an autoincrement field shouldn't behave this way!
I then attempted to reproduce this bug by uploading the same two files to a new database and working through some similar steps. This time, I got this:
So in this database, the autoincrement has worked properly in the 'id' field, but has skipped a number in the 'people_index' field. In this case, the primary key field was still in place when I went back to the schema designer.
This is all happening on Staging, in the project called 'Staging test 2', in the databases 'CSV upload test' and 'CSV upload test 2'. Dave, I'll make you a project admin.