O$ - DAM issue - differences between dev and runtime

Tue Apr 7 12:28:53 EDT 2009

David,

That hazy bit of memory went something like this

$cinst.$default.$insert() returns lvError

Even better

Say you have a list defined as a sql table with an overwritten insert,
you can invoke the built in method from outside the table

lvRowData.$default.$insert()

Nick

-----Original Message-----
From: omnisdev-en-bounces at lists.omnis-dev.com
[mailto:omnisdev-en-bounces at lists.omnis-dev.com] On Behalf Of Nick
Harris
Sent: dinsdag 7 april 2009 18:06
To: OmnisDev List - English
Subject: RE: O$ - DAM issue - differences between dev and runtime

David
Theoretically (as i am back in DML)
I agree that the 'do default' should do the update (and return a flag),
do inherited should execute the method in the superclass (returning the
return value of that method)
No as you say the do default does not return anything useful how about
putting an instance variable in the superclass, in the sql error method
switch it to true, you will be able to peek at that in the sub class.
Another thing, and my memory is very hazy here as I have not used this
technique for five years or more, and I may have invented it in my sleep
;-)
There was specific notation to invoke the standard sql methods.  I have
tried looking in the docs, but that is not very revealing.
Regards
Nick

-----Original Message-----
From: omnisdev-en-bounces at lists.omnis-dev.com
[mailto:omnisdev-en-bounces at lists.omnis-dev.com] On Behalf Of David
Walton
Sent: dinsdag 7 april 2009 16:40
To: OmnisDev List - English
Subject: Re: O$ - DAM issue - differences between dev and runtime

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
>

_____________________________________________________________
Manage your list subscriptions at http://lists.omnis-dev.com
_____________________________________________________________
Manage your list subscriptions at http://lists.omnis-dev.com