[ic] one store gone nuts - OMG it works

[Glenn McCalley]

----- Original Message ----- 
From: "Paul Jordan" <jordan at gishnetwork.com>
To: <interchange-users at icdevgroup.org>
Sent: Sunday, September 09, 2007 6:53 PM
Subject: RE: [ic] one store gone nuts - OMG it works


> interchange-users-bounces at icdevgroup.org wrote:
>> ----- Original Message -----
>> From: "Kevin Walsh" <kevin at cursor.biz>
>> To: <interchange-users at icdevgroup.org>
>> Sent: Sunday, September 09, 2007 5:36 PM
>> Subject: Re: [ic] one store gone nuts - Different, anyway.
>>
>>
>>> Kevin Walsh <kevin at cursor.biz> wrote:
>>>> "Glenn McCalley" <techlist at bnetmd.net> 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
> interchange-users at icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
>