Walaa wrote:
Please check the LLBLGen Pro manual "Using the generated code -> Validation per field or per entity"
Good Luck
Ah ha. I see it now. OK, that's one solution, and a good one. Thank you. I appreciate the answer.
To continue the discussion for those interested....
As I think about it, I guess that I am looking for a more direct way, something a bit more "brute force" and less customized perhaps, something which leverages the meta-data and schema information that already exists in the database about the constraints.
I guess that I am trying to find a way to "ask" the database a question like "what constraint violations, if any, would occur if I tried to save this data?". For example, one could achieve the desired affect if one started a transaction, tried to save the data, caught the exception, rolled back the transaction, and returned the error message. However, as I suggested in a post above, that is a VERY ugly way to do it and I is therefore not acceptable, IMHO. With such a transaction-based-solution, I don't mind hitting the database with an extra call; that is fine-- but, I do mind mucking with the table data, even if it is on a temporary basis.
As a parallel, note that we can already "ask" questions similar to this via LLBLGen objects. For example, checking if a given field is a PK or an FK or something like that, (I forget the actual syntax), is a similar question. That's the kind of functionality that I seek.
I guess my argument for wanting to do this is as follows: the constraint information is already in the database; so, one should try to avoid duplicating it in code. Why? Well, simply because that adds bookkeeping and synchronization overhead, which is error-prone and fragile. As much as one should avoid putting ANY business-rule-information in the database, I would argue here that the constraint information, (which in a loose way IS business-rule-information), must NECESSARILY exist in the database. Therefore, since that information MUST be there, then it should ONLY exist there, if at all possible. As such, it is a kind fo meta-data that the database "knows". I suggest that the solution is that one has to find a good way to "ask" the database what it "knows". And so on.
I am thinking that sort of thing is not easily possible; but, I hope that I am wrong.
If you (or anyone) has any thoughts on the matter, then I would be grateful to hear them.
Thank you.
-- Mark Kamoski