So I’ve just spent a few fun more time than I liked hours trying to work out why a function with the same code in one system is not working in another. Simply put. It turns out in 2022.1.13 at least that you can use Db.Savechanges() against a table that does not have the Updatable flag checked and it throws no errors!
Needless to say there’s some time in my life I will never get back.
Has anyone else encountered this? Next stop tomorrow to log a ticket. I feel that a bit of error handling might be nice here.
If anyone gets a moment and are on a later version of 2022.1.13 it would be useful to know.
So in the References > Tables, the table is Read Only (not updateable) but it allows you to update the table? Or it just allows you to execute Db.SaveChanges()? I know that last was the case in 10.2.700 and still in 2023.1.7. It won’t error on Db.SaveChanges() but it also won’t save any changes.
I think SaveChanges is only available if you have at least one Table checked as Updateable. So, if the table in question isn’t checked, I would assume, the SaveChanges wouldn’t do anything.
I think this is one of those cases where it’s “Working as designed”. You could do a quick lookup after the SaveChanges to see if the SysRevID updated, if not then throw an error…
I’d agree digging into it a bit deeper. I’m thinking if your going to be using Db.SveChanges() then it might be good practice to check any tables to confirm that is set to updatable and if not then throw an exception.
I wonder what the best way to implement this would be? Never use it and just use the BO, or perhaps just call another function at the top of your code passing in list of tables tables that get get used in the code…
Great idea if you need to check if Db.SaveChanges() is working. I think Simon’s issue (and mine at least twice) was that we knew it wasn’t working, just not why it wasn’t working.
Using the BOs ensures you don’t break the base functionality… Updating directly to tables unless it’s a UD field or a description field can lead to unpredictable results. Of course unless you really really know it.
Some would argue that it can be a performance hit, and that might well be correct for earlier versions, but anything I have done lately is super quick…for example adding a misc charge to multiple RMA credit lines in one hit. Sure saves the user a heap of time opening an closing that credit update form.
For me, it’s just following good Object-Oriented programming. The point of the object is to encapsulate all the logic. If I’m writing to the tables, I have to duplicate all the very same logic. Frankly, I don’t know what their code does well enough to duplicate it AND to keep it up-to-date as they change it. They may be updating other tables, performing conditional updates, or whatever. Not to mention all of the security (Company, Site, Field, Method) we bypass by going to the tables directly.
I get it. For those of us who grew up with databases, it’s all we know. Before our time, people wrote to cards and tape with their batch programs. The new kids are calling APIs on queues, event stores, key-value strings, etc. They don’t know the internal tables for Monday.com, Exchange or SharePoint Server, Trello, etc. They just use the API.
Deployed against all good advice. 
The point of the object is to encapsulate all the logic. If I’m writing to the tables, I have to duplicate all the very same logic. Frankly, I don’t know what their code does well enough to duplicate it AND to keep it up-to-date as they change it. They may be updating other tables, performing conditional updates, or whatever. Not to mention all of the security (Company, Site, Field, Method) we bypass by going to the tables directly.