On 2015-02-21, 11:17 AM, "OC" wrote:
Chuck,
On 21. 2. 2015, at 20:09, Chuck Hill
mailto:ch...@gevityinc.com>> wrote:
I think it is a fair expectation that EOF may not properly support optimistic
pessimistic, I guess?
Cough. Yes.
locking. I am not even sure how to set it up properly. Th
Chuck,
On 21. 2. 2015, at 20:09, Chuck Hill wrote:
> I think it is a fair expectation that EOF may not properly support optimistic
pessimistic, I guess?
> locking. I am not even sure how to set it up properly. There are some
> methods on EOEditingContext and EODatabaseContext, and one the
>
I think it is a fair expectation that EOF may not properly support optimistic
locking. I am not even sure how to set it up properly. There are some methods
on EOEditingContext and EODatabaseContext, and one the EODatabaseContext
Delegate.
Chuck
On 2015-02-21, 3:42 AM, "OC" wrote:
Anyway, ba
I don’t know, I suggest asking on the FrontBase developers list.
On 2015-02-21, 2:55 AM, "OC" wrote:
Chuck,
On 20. 2. 2015, at 19:37, Chuck Hill
mailto:ch...@gevityinc.com>> wrote:
One way would be to twist the DB to do the complete restraint to me, something
like to a pseudo-code “inserted_r
Hello there,
after having played for a time with constraints, I have decided to use a
trigger instead -- main reason is that I really want the validation performed
on INSERT only; a constraint might get evaluated in other occassions, too.
Nevertheless, I can't find a decent way of doing that in
Anyway, back to the original question --
On 20. 2. 2015, at 18:27, OC wrote:
>>> Actually _this_ should not be weird, this should be quite a normal code;
>>> the only requirement is that check-and-save, i.e., conceptually,
>>>
>>> ===
>>> if (TEST(eo.someRelationship().someAttribute(),newAttrib
Chuck,
On 20. 2. 2015, at 19:37, Chuck Hill wrote:
>> One way would be to twist the DB to do the complete restraint to me,
>> something like to a pseudo-code “inserted_row.attr>=MAX(SELECT attr FROM
>> this_table WHERE another_attr.isValid) AND couple more similar conditions”
>> -- frankly I
On 2015-02-20, 12:30 PM, "Ramsey Gurley" wrote:
On Feb 20, 2015, at 12:09 PM, OC mailto:o...@ocs.cz>> wrote:
it must pass a slightly more complex test than uniqueness:
- when inserted into PRICE_OFFERS table,
- the newly inserted object must have value in column PRICE, which is higher,
- than
On Feb 20, 2015, at 12:09 PM, OC wrote:
> it must pass a slightly more complex test than uniqueness:
>
> - when inserted into PRICE_OFFERS table,
> - the newly inserted object must have value in column PRICE, which is higher,
> - than any (max) of the already existing objects in that table, whi
Chuck,
On 20. 2. 2015, at 19:37, Chuck Hill wrote:
>> Actually _this_ should not be weird, this should be quite a normal code; the
>> only requirement is that check-and-save, i.e., conceptually,
>> === [1]
>> if (TEST(eo.someRelationship().someAttribute(),newAttributeValue)) {
>>def
>> new
On 2015-02-20, 9:27 AM, "OC" wrote:
Chuck,
Actually _this_ should not be weird, this should be quite a normal code; the
only requirement is that check-and-save, i.e., conceptually,
===
if (TEST(eo.someRelationship().someAttribute(),newAttributeValue)) {
def
new=EOUtilities.createAndInsertI
Chuck,
>> Actually _this_ should not be weird, this should be quite a normal code; the
>> only requirement is that check-and-save, i.e., conceptually,
>>
>> ===
>> if (TEST(eo.someRelationship().someAttribute(),newAttributeValue)) {
>> def
>> new=EOUtilities.createAndInsertInstance(eo.editing
12 matches
Mail list logo
