O$ - DAM issue - differences between dev and runtime

[Doug Kuyvenhoven]

Hi David:

As far as I know if you put in

	Do default Returns #F

#F should correctly return true or false. If you are testing the code  
I recommend to put the breakpoint AFTER the "Do default", not on or  
before that line of code.

In my first version of StudioWorks I override the default table class  
methods... but eventually I got to the point where I regretted doing  
so. In a later major new release I abandoned overriding default table  
class methods and instead added similarly named custom methods to my  
superclass table class.

	$updateRow
	$insertRow
	$deleteRow

	$doworkBatch
	$doupdatesBatch
	$dodeletesBatch
	$doinsertsBatch

That way the Omnis default table class methods were left undisturbed  
and still useable... and my customized methods where free to do their  
own version of the default method.

Just my own 2 cents after having travelled down that road and back. :-)


Doug Kuyvenhoven
Vencor Software - www.vencor.ca
AutoUpdater - www.vencor.ca/autoupdater/
StudioTips - www.vencor.ca/studiotips/
StudioWorks - www.vencor.ca/studioworks/

On 7-Apr-09, at 10:39 AM, David Walton wrote:

> Yeah, thanks but that still doesn't work. I don't really understand  
> the do inherited. Inherited from what? It is being called by my  
> table superclass.
>
> What I really want it to do is the standard table update. That's why  
> I am doing the do default. I think that inherited won't work if  
> there's nothing being inherited.
>
> Also, I do have an sql error method in the table... but since the  
> return value on my update isn't able to tell me anything, I can't  
> determine whether there was an error or not.
>
> Somewhat of a catch 22 there.
>
> Weird that I've never had this problem before. Maybe I should go  
> back to a prior version of studio...
>
> (BTW this is with 4.3.1.4)
>
> On Apr 7, 2009, at 10:11 AM, Phil Potter wrote:
>
>> Hi David,
>>
>> did you try "Do Inherited" without the $ ?
>>
>> As for errors, create a $sqlerror method within the table, which is  
>> called when you get a SQL error.
>>
>> Although personally I'd have a table superclass with this $sqlerror  
>> method within it, so that you only need it in one place for all the  
>> tables you may create.
>>
>> Regards
>> Phil.
>>
>> In article <82295ABB-AEDC-4902-B60F-7949836093C8 at charlie.housing.admin.nyu.edu 
>> >, David Walton <omuser at charlie.housing.admin.nyu.edu> writes
>>> Hi again,
>>>
>>> This do $inherited doesn't work - nor does do $inherited.$update
>>>
>>> Do default does work, but does not return an understandable value.
>>>
>>> Which begs another question: If you use a table class to override  
>>> the standard table $update() method, how would you check for sql  
>>> errors?
>>>
>>> For now, I'm using a check to see whether $cinst.$rowsaffected is  
>>> greater than zero.
>>>
>>> Thanks.
>>>
>>> On Apr 7, 2009, at 8:46 AM, Steve Finger wrote:
>>>
>>>> Hi,
>>>>
>>>> Now I'm confused. In my table classes I override $update all the  
>>>> time and at the end put
>>>>
>>>> Do default Returns %flag
>>>>
>>>> %flag is a local variable and it returns 1 if successful and 0 if  
>>>> not
>>>>
>>>> In my only experience with Oracle and SQL Server the Do default  
>>>> works the same with the 0 or 1 result.
>>>>
>>>> I think (but I'm going from memory) there may have been a time it  
>>>> returned null from an sql statement that ended up being totally  
>>>> messed up and I guess the Dam didn't know what to do with it.
>>>>
>>>> Steve Finger
>>>>
>>>> Bastiaan Olij wrote:
>>>>> Hi David,
>>>>> As you are overrriding $update, do default is not the correct  
>>>>> way to
>>>>> invoke the standard logic.
>>>>> Try either doing a "do inherited" or what I find easier/better  
>>>>> myself:
>>>>> do $inherited.$update() returns lvSuccess
>>>>> Which allows you to parse any additional parameters.
>>>>> I can't remember off the top of my head when you had to use do  
>>>>> default.
>>>>> I hardly use that one in my code.
>>>>> Greetz,
>>>>> Bas
>>>>> David Walton wrote:
>>>>>> Okay... no responses. Let's try again.
>>>>>>
>>>>>> I have a table method that is called $update. It processes some
>>>>>> history, checks that the user has changed some values, then says
>>>>>> default" with a return value. The problem is that I get different
>>>>>> results from the return value on the do default in runtime than  
>>>>>> in
>>>>>> development.
>>>>>>
>>>>>> Can someone tell me what I should expect from the return value  
>>>>>> on a
>>>>>> default? Is it boolean, numeric, etc? It seems to be returning  
>>>>>> a blank
>>>>>> (like '').
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>