O$ - DAM issue - differences between dev and runtime

[David Walton]

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.
>>>>>
>>>> _____________________________________________________________
>>>> Manage your list subscriptions at http://lists.omnis-dev.com
>>> _____________________________________________________________
>>> Manage your list subscriptions at http://lists.omnis-dev.com
>>>
>>
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
>
> -- 
> Phil Potter <phil at pgpotter.demon.co.uk>
> Based in Chester in the UK
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
>