All --

The question is...

Is there a way to get constraint violation information without a save?

(Note that I would NOT want to use a transaction and automatically rollback. I need something better than that.)

What do you think?

Please advise.

Thank you.

-- Mark Kamoski

Do you mean a database constraint violation? Please elaborate a little bit more.

Did you consider using Validation per field or per entity?

Thanks.

Walaa wrote:

Do you mean a database constraint violation?

Yes.

Walaa wrote:

Did you consider using Validation per field or per entity?

No. Please elaborate a little bit more. I am not familiar with that technique.

Thank you.

-- Mark Kamoski

Please check the LLBLGen Pro manual "Using the generated code -> Validation per field or per entity" Good Luck

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

mkamoski wrote:

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.

Yes, but checking to see if a field has a Unique Constraint for example is different than asking if the data in the entity violates that constraint. The later can not be know without looking at the db anyway.

The main question here is, do you want to be pro-active or reactive. I acutally plan on doing a spike soon to see if I could come up with a generic way to trap for constraint violations. Haven't worked on it yet though.

BOb