Description: If in Base you have a table with a Primary Key and a Foreign key and go to Base index design (ie: edit the table and go to: tools -> Index design) you can see two entries in the list giving the index of the table. The entry coming from the primary key can't be delete or modified: It appears in read-only mode in the graphical interface. On the other hand, regarding the foreign key, you have the possibility to delete or modify it and if you want to delete it, then Base launches a command that does not allow you to delete a foreign key but that of deleting an index. It seems to me that the display of any foreign key in Base indexes should be read-only like for primary keys. Steps to Reproduce: 1. Go to Base en create two table with 2 column ID and FK of same type and the column ID declared has primary key. 2. In Base go to: Tools -> Relationships... and create a new relation between the column ID of the fist table and the column FK of the second table. 3. Edit the second table in Base and open the index with: Tools -> Index Design 4. You will be able to delete the foreign key and if you try you will get an error. 3. Actual Results: It is possible to delete a foreign key in Base indexes design. Expected Results: It should not be possible to delete a foreign key in Base Indexes design. Reproducible: Always User Profile Reset: Yes Additional Info: There may be a good reason why a foreign key can be removed from index management. However, it cannot work as it is.
Well, it seems easy to get around this problem: When deleting a foreign key, the dropByName() method is called by Base in the container managing the indexes (i.e., css.sdbcx.IndexContainer). So you just need to check if a foreign key with the same name exists in the key container (i.e. css.sdbcx.KeyContainer) and if so, use this key container to perform the drop (i.e. call dropByName on this container). I'm still surprised that Base doesn't make this choice beforehand and that we're forced to perform this check. Now, I don't know much about using the SDBC API.
Well, I'll close by specifying that this is not a bug in the absence of more information.