This project is read-only.

How to know if accessor Execute/WriteEntity was successful?

Apr 3, 2013 at 9:27 PM
Both methods does not have a return value; currently what I'm doing is:
   Accessor.Execute("UPDATE patientcounter SET counter =(SELECT MAX(counter) FROM patientcounter LIMIT 1) + 1")
End Try
Don't know if Record.State property change from "New" To "Current" mean success.

If newItem.Record.State.ToString() = "Current" Then
                    Return 1
                    Return 0
                End If
But don't think this is the right way.

How can we control exceptions or success?

Apr 4, 2013 at 4:08 PM
Hi Oscar,

I think this may be a matter of philosophy here. In order for me to return a false for and unsuccessful write, I would have to trap the exception that occurred. I don't think this would be desirable in most situations. To your second point, entities do have their state reset to "current" after they have been written. However, I wondering if what you're missing is the "rows affected" value return from a typical execute call. I can see how that might be a nice to have. However, the prevailing philosophy, is that DrivenDb will never not write and entity unless it has not been changed.

I hope this answers your question. Let me know. Thanks!

Apr 6, 2013 at 12:54 AM
Hi Tony,

Understand your point, but still wonder how flow control must be re/designed in order to know what happened and what to do with DrivenDb ; which BTW, was one of the reasons to move to a simple ORM. Got tired of writing endless try catch, return values, transactions, etc. etc.

Don't get me wrong, DrivenDb has great features, One size fits all 'philosophy' does not apply to what we do. :)

Regards, Oscar.
Apr 6, 2013 at 12:38 PM
Unfortunately, I think we may end up with a difference of opinion on this. To me, an exception represents a bug in the code. To suppress an exception would be to hide a bug. And while I think I can see some value in returning the rows affected, the "void write()" methods of DrivenDb should be as trustworthy as any "void anymethod()" call you've written in your own code. I think you'll be hard-pressed to find a third-party library that will suppress errors for you.