O$ - DAM issue - differences between dev and runtime

[Bastiaan Olij]

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