Re: [ic] one store gone nuts - OMG it works

["Glenn McCalley" <suppressed>]

----- Original Message ----- 
From: "Paul Jordan" <suppressed>
To: <suppressed>
Sent: Sunday, September 09, 2007 6:53 PM
Subject: RE: [ic] one store gone nuts - OMG it works


> suppressed wrote:
> > ----- Original Message -----
> > From: "Kevin Walsh" <suppressed>
> > To: <suppressed>
> > Sent: Sunday, September 09, 2007 5:36 PM
> > Subject: Re: [ic] one store gone nuts - Different, anyway.
> >
> >
> > > Kevin Walsh <suppressed> wrote:
> > > > "Glenn McCalley" <suppressed> wrote:
> > > > > [if type=explicit compare=|
> > > > > [calc]Debug('creating user loc 1');[/calc]
> > > > > [userdb
> > > > > function=new_account
> > > > > assign_username=1
> > > > > password='[value zip]'
> > > > > verify='[value zip]'
> > > > > ]
> > > > > > ]
> > > > Change that code so that the [calc] block looks like this:
> > > >
> > > >     [calc]Debug('creating user loc 1'); undef;[/calc]
> > > >
> > > > Seeing the code always helps. :-)
> > > Better still, put the [calc] block outside of the [if] tag's compare
> > > parameter.  Perhaps on the line above.
> > Understand, that was the purpose of putting it in there to see if that
> > branch was being taken.  ...BUT...
> > ...OMG...
> > I moved it outside and the problem went away...
> > Does this mean - no can't be can it - having that debug statement in
> > there was causing this thing to throw a data exception?
> > And that my problem really went away hours and hours ago, replaced by
> > this? Seems so... arrgg working in IC is sometimes having to work in
> > 2 languages at once seems like.  Mind shift problems.
> >
> > I love computers...
> > ...and this group.
> > THANK YOU Kevin!
> > And Peter, Doc, Greg, Ron, Marty, Aaron, Paul, JT and to anyone I
> > forgot sorry.
> >
> > Glenn.
>
> Glenn, so what was the problem after all, still unknown?
>
> The only time I have seen anything like your original problem was when the
> counter file and userdb were not in sync. This can happen several ways. 
> One
> way is improper importing of user records. Another is by creating 
> usernames
> similar to UNNNNN (via create new account) that are higher than a auto
> usernames currently being issued by the cart. If the store is not 
> filtering
> those new usernames out (which should be standard), then one could put a
> stop the store very easily. Go to your shop and make an account with the
> username U05000, and wait :-)
>
> It'd be nice to know what was going on with your shop.
>
> Paul
Paul, best I can tell it was a good old-fashioned corrupt file.  To 
summarize:

- The original problem was that -every- order for this store (others on same 
IC server OK) would throw a 500 Internal Server Error upon clicking the 
final "Place Order" button on checkout.

- The CC charge processed fine (had to void a lot of charges as people 
clicked back and Place order again and again.  No receipts were issued, no 
order files created in orders lib.

- Believing it was a Perl problem of some sort I upgraded Perl (5.8.5 to 
5.8.8) and re-installed Bundle::InterchangeKitchenSink no help.  That turned 
out to be more of a task than I'd thought, but should have been up to date 
anyway.

- Got advice from list on how to construct [calc]debug('message');[/calc] 
implants for log_transaction and after moving those around and trying orders 
determined that things were dying in the user auto-create process.

- Went to export the user file (using the UI) to examine the data and the 
export process threw a 500.  Ah Ha bad data.

- Decided the userdb.db itself was hosed so deleted it and recreated an 
empty database (auto-recreate from userdb.txt with just the column header 
record) and reset the user counter to U00000.  No damage to client he 
doesn't use anything on the back end anyway.

- At this time - here is where I think I screwed up - I put a [calc]debug 
statement within the compare part of the "if" statement above and I believe 
that -I- thus killed the user create process that a clean userdb.db file 
resurrected.  So the problem appeared to change.

Moral - change one thing at a time.

On advice from Kevin Walsh I relocated that statement and Bingo changed 
problem fixed.

The store in question if you are interested is a ticket sales store for wine 
festivals, beer festivals, octoberfests and such.  www.mooreatix.com  Of 
course this happened 3 days before a major wine event which -really- earned 
us a lot of credibility but we'll deal with that tomorrow.

Thanks for asking,
Glenn.


> _______________________________________________
> interchange-users mailing list
> suppressed
> http://www.icdevgroup.org/mailman/listinfo/interchange-users

_______________________________________________
interchange-users mailing list
suppressed
http://www.icdevgroup.org/mailman/listinfo/interchange-users