Hugh Sasse <hgs / dmu.ac.uk> wrote:
> I've delayed replying for a bit because lots of good stuff is
> coming in, and I didn't want to stem the flow or divert it, ...
>
> On Thu, 12 Oct 2006, Richard Conroy wrote:
>
>> On 10/12/06, Hugh Sasse <hgs / dmu.ac.uk> wrote:
>>> I have a large application (which is actually a Rails app) which is
>>> behaving oddly (I can change items in a DB twice, but 4 times
>>> fails), and using all the conventional approaches I have learned for
>>> debugging (printing things out, logging to files, ...)
>>
>> I am not being pedantic here, but have you not tried a debugger?
>
> I'm not yet clear where to set the breakpoints, and so on, because
> I don't understand enough about the nature of the failure.  But
> I probably need to re-examine the Ruby debugger, because my knowledge
> of it's capabilities is somewhat limited....   So, up to now, no,
> I have avoided this approach.

Maybe set_trace_func with a complete application trace (of the part that 
fails) helps in understanding what methods get called.  Maybe you then 
realize immediately where the bug is (some method called too often or not at 
all).  If not you might get an idea where to place your breakpoints or 
detailed debug output.

> Well, the logs show the save! commands are getting called OK, with
> the right values.  I've said I've no reason to suspect the database.
> Leaving reason aside, my emotions tell me that maybe I should
> suspect, having read rather uncomplimentary stuff about MySQL,
> advocating PostgreSQL, but I don't know enough about the DB issues
> to be sure.  This is my first serious DB project.  So for now I
> suspect my own code.  So I'll need to refactor to improve testing.

Just some questions into the blue: are there triggers involved on DB level? 
Do you use stored procedures vs. simple INSERT, UPDATE, DELETE, SELECT?

Kind regards

    robert