In RS 2012, using a REALSQLDatabase, I was able to edit a recordset even if the table didn’t have a primary key. With Xojo, I get an error that the recordset cannot be edited because there is no primary key. Was this change intentional and I have to go back and change the table(s) to add a primary key or is this a bug?
The table in question is where I have the program store its preferences and only has, and will ever only have, one record. A primary key on a one-record table is kinda superfluous.
This change was intentional. SQLite requires the primary key in order to do the UPDATE. RealSQLDatabase would embed the rowid for you behind the scenes, but this caused lots of problems with more complex SQL statements.
If you don’t want to add your own primary key, you can probably get away with just including rowid in your SELECT statement.
[quote=11341:@Dale Arends]In RS 2012, using a REALSQLDatabase, I was able to edit a recordset even if the table didn’t have a primary key. With Xojo, I get an error that the recordset cannot be edited because there is no primary key. Was this change intentional and I have to go back and change the table(s) to add a primary key or is this a bug?
The table in question is where I have the program store its preferences and only has, and will ever only have, one record. A primary key on a one-record table is kinda superfluous.[/quote]
Every table in REAL SQL and SQLIte has a primary even if you dont define one - its called rowid
But if you DONT put on on there you can run into issues with them
Highly recommend that you define your own PrimaryKey field (preferably auto increment that you cannot set in the Xojo DB editor) for SQLite. While you can use rowid there can be issues depending upon it always staying the same. If you define the primary key it’s a bit more portable when moving to another db.