I'm on a project using an old version of LLBLGen Pro (1.0.2004.2). We are implementing a mechanism in our application to handle error messages for constraint violations. If a constraint if violated, then we catch the exception, parse out the name of the constraint, and look it up in the database to retrieve a user-friendly error message. This is helpful in centralizing knowledge of what constitutes "valid data" in the database itself.

My question is: short of wrapping each database update in code to look up these error messages, would we be better off catching the exception at a low level within LLBLGen and rethrowing an exception with the friendly message? If so, what template(s) would we need to modify to do this?

Thanks.

Are you using the Adapter or SelfServicing model?

Self-servicing

You may build your own runtime libraries (since you have the source code). Modify the Save method in the EntityBase class from which all the entities are derived.

Or you may leave the runtime libraries intact and you may either override the Save method in each entity, or create an intermediate class that derive from the EntityBase and from which all entities should derive.

Thanks. This wouldn't catch constraint violations that occur when a stored procedure is executed though, right? For example, if table X has a constraint on it that column c cannot be 0, then then modifying the Save method for all entities (or just entity X) could catch that exception. But if there's a stored procedure that modifies table X and violates that constraint, then this modification wouldn't catch exception that could arise when running that stored procedure. Is there a central spot which could catch both possibilities? I realize I can probably figure this out on my own by reviewing the code, but wanted to get an authoritative answer from people more experienced with LLBLGen than me.

Thanks.

There's no central spot for stored proc errors AND entity DML errors, as stored procs are called via ADO.NET code executed in the generated DbUtils class, while the entity DML sql is ran inside the Dao base.

Thanks!