O$ - DAM issue - differences between dev and runtime

[David Walton]

Hi Bas,

You are right about Do default working. I have been creating custom  
update, insert and delete methods via table class for a long time and  
have never had the problem with the return value being anything other  
than true or false. I was thinking this was a new development  
(feature??) but it seems odd that in Development mode, it works as  
expected but in Runtime it doesn't. Makes it rather hard to deploy  
apps if you have to keep jumping from one to the other to debug!

Of course, I'm always sure I'm missing something - hence the posting.  
Thanks for your help.

BTW, I'm not checking for the flag after the do default anymore. I'm  
looking at $cinst.$rowsaffected to see whether the update worked.  
Seems to work in both runtime and development.

David.

On Apr 7, 2009, at 5:00 PM, Bastiaan Olij wrote:

> Hey David
>
> As mentioned in another mail, I must have mixed this up. Basically the
> table class contains a $insert, $update and $delete method that you
> either call from wherever you are using a list/row defined from a  
> table
> class, or it gets called indirectly through the smartlist commands.  
> You
> are in fact overriding these methods with your own logic which is  
> why I
> thought $inherited.$update is the right course of action. This must be
> one of those funny exceptions to the rule :)
>
> Do default should work then which is why I do not get why it doesn't
> return a success/failure flag. The only situation I have had this in  
> is
> when the session object/statement object wasn't set, but then nothing
> would happen, the update would go ignored, so that won't be the case.
>
> As for error handling. Every internal method of the table class  
> calls a
> method called $sqlerror when an error accures. Simply override this
> method in your table base class and put your error handling in there.
> Check earlier mails from me on the subject for some sample $sqlerror
> code. I tent to log the error and set an instance variable in my table
> class that I can get at later on.
>
> Greetz,
>
> Bas
>
>
> David Walton wrote:
>> 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  "Do
>>>>> 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 do
>>>>> 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
>>
>
>
> -- 
> Kindest Regards,
>
> Bastiaan Olij
> e-mail/MSN: bastiaan at basenlily.nl
> web: http://www.basenlily.nl
> Skype: Mux213
> http://www.linkedin.com/in/bastiaanolij
>
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
>