[ic] catalog working, no admin/login, unable to checkout

[IC Support]

Peter said: 

> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org 
> [mailto:interchange-users-bounces at icdevgroup.org] On Behalf Of Peter
> Sent: Friday, September 02, 2011 5:33 PM
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] catalog working, no admin/login, unable to checkout
> 
> On 03/09/11 02:59, IC Support wrote:
> > And this is what has heppened since my last email. I tried 
> configuring 
> > and running make and make test as root. You are saying that I WAS 
> > doing it correctly (running make test as curt), so this may 
> all be moot.
> > 
> > # cd perl-5.12.4
> > # ./Configure -des -Dprefix=/usr/local/perl-5.12.4 # make # 
> make test 
> > # make install # cd /usr/local # sudo ln -s perl-5.12.4 perl
> > 
> > This got me through make test and the install error free. I got 
> > through Text-Query issues and finished the perl install,
> 
> Right, this makes sense since the test was failing on a 
> permissions error running it as root would likely bypass the 
> problem.  I'm still not sure what the actual issue was but it 
> doesn't look very serious to me.
> What concerns me is that I'm unable to reproduce it.
> 
> > however, when I do:
> > 
> > /usr/bin/perl -v
> > This is perl, v5.8.8 built for x86_64-linux-thread-multi
> > 
> > This perl was built by DirectAdmin when they setup my new VPS
> 
> Actually, that's the system perl.
> 
> > however, /usr/local/bin/perl
> > This is perl, v5.10.0 built for x86_64-linux-v
> > 
> > This is a version I tried as root (which you once 
> questioned my choice 
> > of version), it won't go away, how can I get it out of there? Do I 
> > just remove /usr/local/bin/perl? Again, maybe I should not 
> be doing this as root.
> 
> I think you can go into the build directory where you built 
> that particular perl and do: make uninstall
> 
> The 5.12.4 perl you just built will be at 
> /usr/local/perl-5.12.4/bin/perl.
> 
> > whereis perl
> > perl: /usr/src/perl-5.12.4/perl.c /usr/src/perl-5.12.4/perl.h 
> > /usr/src/perl-5.12.4/perl.o /usr/src/perl-5.12.4/perl /usr/bin/perl 
> > /usr/local/bin/perl /usr/local/perl /usr/share/man/man1/perl.1.gz
> 
> Right, it won't show up on whereis because it's not in your 
> path.  You can either symlink the perl binary to someplace in 
> your path or just call it with an absolute path, ie:
> /usr/local/perl-5.12.4/bin/perl --version
> 
> Really it is probably best to leave that perl out of the path 
> so it doesn't interfere with your system perl.

OK, so I now have a test cat FULLY working and MY cat is running in admin
area. I had to remove the .gdbm and .sql files from products folder. I was
able to get into the user frontend after doing this, place an order, log in,
complete the order, view the receipt, then when going to home page or any
other page it resulted in "Internal server error". My cat error log has this
(and always seemed to have this error):

74.117.242.45 cnXuas58:74.117.242.45 - [11/September/2011:17:47:02 -0400]
fts1 /cgi-bin/fts1/index.html Runtime error: Can't locate object method
"func" via package "DBI::db" at
/usr/local/perl-5.12.4/lib/site_perl/5.12.4/x86_64-linux/DBD/mysql.pm line
227.

Things seem to be up-to-date, though I don't see a DBI::db nor can I find
one to install:
# perl -MDBI -e 'DBI->installed_versions'
  Perl            : 5.012004    (x86_64-linux)
  OS              : linux       (2.6.18-238.19.1.el5xen)
  DBI             : 1.616
  DBD::mysql      : 4.020
  DBD::Sponge     : 12.010002
  DBD::Proxy      : 0.2004
  DBD::Multiplex  : 2.11
  DBD::Gofer      : 0.014282
  DBD::File       : 0.40
  DBD::ExampleP   : 12.014310
  DBD::DBM        : 0.06

# mysql -V
mysql  Ver 14.14 Distrib 5.1.57, for unknown-linux-gnu (x86_64) using
readline 5.1

# /usr/local/bin/perl -MCPAN -eshell
 cpan[2]> install DBI
DBI is up to date (1.616).
 
cpan[3]> install DBD::mysql
DBD::mysql is up to date (4.020).

Here are a few lines from mysql.pm, hope it doesn't break:

192 package DBD::mysql::db; # ====== DATABASE ======
193 use strict;
194 use DBI qw(:sql_types);
195
196 %DBD::mysql::db::db2ANSI = ("INT"   =>  "INTEGER",
197                            "CHAR"  =>  "CHAR",
198                            "REAL"  =>  "REAL",
199                            "IDENT" =>  "DECIMAL"
200                           );
201
202 ### ANSI datatype mapping to mSQL datatypes
203 %DBD::mysql::db::ANSI2db = ("CHAR"          => "CHAR",
204                            "VARCHAR"       => "CHAR",
205                            "LONGVARCHAR"   => "CHAR",
206                            "NUMERIC"       => "INTEGER",
207                            "DECIMAL"       => "INTEGER",
208                            "BIT"           => "INTEGER",
209                            "TINYINT"       => "INTEGER",
210                            "SMALLINT"      => "INTEGER",
211                            "INTEGER"       => "INTEGER",
212                            "BIGINT"        => "INTEGER",
213                            "REAL"          => "REAL",
214                            "FLOAT"         => "REAL",
215                            "DOUBLE"        => "REAL",
216                            "BINARY"        => "CHAR",
217                            "VARBINARY"     => "CHAR",
218                            "LONGVARBINARY" => "CHAR",
219                            "DATE"          => "CHAR",
220                            "TIME"          => "CHAR",
221                            "TIMESTAMP"     => "CHAR"
222                           );
223
224 sub prepare {
225     my($dbh, $statement, $attribs)= @_;
226
227     return unless $dbh->func('_async_check');

[end]


Any ideas out there?

Curt