How much control do we have on the SQL used to do DB related stuff ( like inserts, updates etc )

We use a Concurrency Time Stamp and have some internal logic applied whenever we get data out of and into DB ( Oracle )

We want to see if it is easy enough to change the SQL used ( probably in your templates) or some other way to override the SQL generation etc..

I'm not sure what you want to accomplish (i.e.: what that 'internal logic' does). Would you mind to elaborate on that a bit so I can point you to the functionality which does this in LLBLGen Pro?

jakkamma wrote:

How much control do we have on the SQL used to do DB related stuff ( like inserts, updates etc )

We use a Concurrency Time Stamp and have some internal logic applied whenever we get data out of and into DB ( Oracle )

We want to see if it is easy enough to change the SQL used ( probably in your templates) or some other way to override the SQL generation etc..

Frans, perhaps he is trying to add the rowstamp to the WHERE clause on updates in order to implement optimistic oncurrency.

JimFoye wrote:

jakkamma wrote:

How much control do we have on the SQL used to do DB related stuff ( like inserts, updates etc )

We use a Concurrency Time Stamp and have some internal logic applied whenever we get data out of and into DB ( Oracle )

We want to see if it is easy enough to change the SQL used ( probably in your templates) or some other way to override the SQL generation etc..

Frans, perhaps he is trying to add the rowstamp to the WHERE clause on updates in order to implement optimistic oncurrency.

Could be, in that case, an IConcurrentPredicateFactory implementation as explained in the documentation would suffice.

We have a concurrency time stamp field on each of out tables that updated via a trigger after each insert or update. The stored procedures that handle the inserts and updates for each table must be passed the concurrency time stamp for each row updated. If the parameter does not match the concurrency stamp on the record, the stored procedure raises an error to indicate the record was not updated.

Since this field is updated via a trigger, after each insert or update we have to get the new concurrency stamp for the record that was just committed.

I will look into the predicate factory, but do you think this can be acheived

That can't be done. Trigger generated values can't be retrieved by the sql generated.

jakkamma wrote:

We have a concurrency time stamp field on each of out tables that updated via a trigger after each insert or update. The stored procedures that handle the inserts and updates for each table must be passed the concurrency time stamp for each row updated. If the parameter does not match the concurrency stamp on the record, the stored procedure raises an error to indicate the record was not updated.

Since this field is updated via a trigger, after each insert or update we have to get the new concurrency stamp for the record that was just committed.

I will look into the predicate factory, but do you think this can be acheived

What database are you using? I don't know about Oracle, but SQL Server will do this for you.