Moving a project from a not so old version of RB is really a pain this time… (not talking about the fact that a recordset with no record is no longer EOF but nil… I’ve had to change a ton of “if” statements)

Of course, it’s not too hard to simulate the old behavior if you have a global database object, you can just add a gDb.Commit to Application Close. I also try to always commit after a logical task in the program is complete, but there’s always the chance I missed a spot.

Most of my database projects use a standard DB object that deals with transactions and multiple database types, and has Autocommit set to false anyway. I only noticed when I loaded in an existing “quick and dirty” project which doesn’t use it, and it took a few minutes to work out what was wrong -but of course I knew the code worked previously, and what Commit/Autocommit is all about anyway.

What the default should be is fairly arbitrary – good practice database is for Autocommit to be false, so it is fine for RB to default to that _providing this is made clear to users_. So IMO the fault is in the Language Reference and examples in not making clear to users what the implications are; and in RS not highlighting this as a “major change” for upgrading users.

From RS’s point of view it would not appear a major change (AIUI it will be one switch in the compilation of the SQLite code) but the change of almost any default will affect a lot of users. Likewise with the introduction of Foreign Key constraints in SQLite (yipee!) the SQLite default is having this off, and if RB shipped with this on, this would need to be highlighted even though it would affect hardly any upgrading users. (Incidentally, to switch it on using a Pragma command, you cannot be in a multistatement transaction, so having Autocommit true by default would simplify switching Foreign Key constraints on )