-
We got an error that says, that we got "edit Bestellnummer is not a primary key, there are some duplicate values." and I cannot safe any of the changes at the moment.
-
There are two order with the same number "95" and I cannot change the number, nor I can delete the orders.
Hi @opsilon_production ,
Could you please share some print screens of the query's?
I got into a weird stuck position like this too.
I was able to use the postgres connection info and PG Admin to connect and fix the issue.
That seems to be a bit complicated. Could you explain the steps?
sure!
grab your connection info from Retool
Download PG Admin
Add your databases from the Retool info
Connect and use the left side tree to navigate to the offending table
Now you should be able to use some SQL and fix that record.
now this is from ChatGPT, but can you do something like this
SELECT id, COUNT(*)
FROM your_table
GROUP BY id
HAVING COUNT(*) > 1;
to see what records might be duplicates?
or.... if you are more hands on... export the table to CSV and look in excel to see what might be the issue. manually fix things, then import it back into the table.
- Do you have the table set up with
Bestellnummer
as the key? This should give you a warning if the value isn't unique in the editor. - Is the orders (or whatever) table also setup with
Bestellnummer
as a primary key in the database, or is a different field the key? IfBestellnummer
is the actual table PK, you shouldn't be able to have two records with the sameBestellnummer
, so perhaps there is a generated key instead? IfBestellnummer
really is/should be the PK, you should update the table definition. Or if it should really be the other field, you can enforce a unique constraint, but I'm not sure how to set that up in the Retool UI (like @khill-fbmc I typically use PGAdmin to access the Retool DB).
Hi @opsilon_production! Welcome to the community.
As the others here have pointed out, the most straightforward way to fix this particular issue is to connect to your database with a GUI tool, find the offending record, and manually fix the conflict. The other option is to use some other field that uniquely identifies the record, assuming one exists, when writing the update query:
In the longer term, I would strongly recommend ensuring that you properly set a primary key and necessary validations on your database tables! Doing so would prevent issues like this in the future.
Let me know if you have any questions about how to do any of this.